Making a Backup Of your Model

It is an excellent idea to make a backup of your model from time to time.  This could be useful if you want to go back and open a previous model version.  In order to do that, you should periodically make a complete backup of your model and any additional files it might need.  You might not be able to run an old model if you don’t.  The complete archived model should include the same elements you would need to include if you sent the model to someone else to run.  Every model might not have all of these elements, but if they do, store them with that current version of the model.  The list is as follows:

• Model
• Custom libraries *
• Custom Include files **
• Pictures used for animation
• External Data Files you are Importing from or Exporting to

* You don't need to backup the standard libraries which are installed with ExtendSim.  You only need to back up your custom libraries that are used in the model if you have any.  You might not have any but you will know it if you do.

** You don't need to backup the standard include files which are installed with ExtendSim.  You only need to back up your custom include files if you use any in custom block or the standard Equation blocks.

Consider one simple example of why you want to archive files along with the model itself.  Suppose we have an Excel workbook that is used to import data from the beginning of the run.  Let's say we have one tab for each of the input tables.  When we made a backup of the model, we did not back up anything other than the model.  Suppose we start working on the input data and made some changes to the model and the Excel workbook.  If we wanted to open the previous model and run it, we would have the archived model but we didn’t backup the spreadsheet so we would only have the updated spreadsheet.  The old model wouldn't understand what to do with this updated Excel file.  There would be a mismatch.  We would be able to open the model up in this case, but we couldn't run the model. 

The same concept applies to all the other files in the list above.  If we don't include them in the model backup, then when we go and open the backup model it may or may not work properly if there have been changes to the library files, include files, pictures, or data files.  These files can change over time as you enhance your model so it would be a great idea to keep a copy of these files with the model backup.

I use WinZip to make a complete backup of all the required files, but other tools could be used as well.  If you are working in a group of model developers, and everyone is working on the model, then something more advanced should be used which allows each user to "check in" changes on each individual file.  Source control tools can be used here.  The source control tools work well for keeping track of changes if the users document changes appropriately.

If you need to send your model to someone else to run, this same backup can be used.  Just don’t forget to include all necessary files. Your model might not contain all the files in this list, but if it does, then you will need to include it in the backup. 

Best Practices for Modeling

Below are some best practices for modeling.

Document first

Don’t wait until the end of model development to start the documentation process.  Documentation should help the developer communicate with the subject matter experts regarding what needs to be included in the model and the assumptions the model will make.  Do the documentation first and validate it with the SME.  Let the documentation help guide development so the constructs will be developed only ONCE!  You will most likely pay a high penalty by having to rework the complex constructs if you don’t address documentation first.  Documentation before construction will help reduce wasteful and time-consuming rework.  Build the model right the FIRST time!  This will help the model builder.

Test as you go

Don’t wait to the end of model development to start testing.  Test as you build.  If you wait until the end to verify the model works correctly, it will take much longer to find bugs because you have to search through the entire model. Build the model in small chunks and test thoroughly as you go.  If you test as you go, the new bugs will be in the constructs you have just built.  You will be focused on a smaller construct to look for the bug while that logic is fresh on your mind.  This is such a crucial aspect of the modeling process that it deserves mentioning more than once!

Build a clean model as you go

Don’t wait until the end of model development to start cleaning up the model.  Messy models take much longer to debug! You might build a construct today and not touch it again for a few weeks or months.  As a result, you will forget the details in the complex constructs.  A messy model is confusing once you return to it, and it requires you to spend extra time trying to remember what each construct is doing. A clean and well-built model is much easier to read and understand, which results in spending less time finding errors.  This will help the model builder.

Build the interface first

The interface should allow the model user quick and easy access to important input and output variables and various model functions.  If the user interface is not created until the end of development, then you have missed out on a fabulous opportunity to use those quick access features.  Not using a model interface will slow model development because you are taking the long way to do things.  Creating it at the beginning helps guide the developer with a clearer picture of what should or should not be in the user interface because the variables and tools have been used throughout the entire process. Beginning with the interface also leads the developer to think about the end product first and clarifies the process of building toward that endpoint.  This will help the model builder.

Use Animation for Debugging

Don't wait until the end to add animation.  Animation can and should be used as a way to help detect bugs in your model in addition to making it look pretty.  So consider adding nice animation from the start.  

Ask for help

Ask for help when needed.   If you are new to modeling, your first task should be finding someone who can help when you need it.  Your go-to person may be a more experienced coworker or an instructor in a training class.  While there’s real and irreplaceable value in learning through your own trial and error, part of the learning process is in knowing when it’s time to move on and ask for help.  Don’t waste excessive time trying to figure out how to do something. 

Use the buddy system

Don’t go off on tangents or get sidetracked.  Modeling can sometimes be more effective if you work with a buddy.  When you are modeling on your own it is easy to go down a path that is nonproductive and diverts you from the primary goal.  When you model with a buddy, you are more likely to get back on the right path quickly because you can encourage each other to stay focused. Modeling with someone else tends to work like bumpers in a bowling alley.

Memory Management Tips

I have a few memory management tips that I thought I would share.   If you have other debugging tips then please share them with us.

The Memory Usage Block in the Utility Library 

The Memory Usage block will show you the amount of memory each block, each h-block, and each database table are using.  This list can be sorted (by clicking at the top of the column) to show you which ones are consuming the most.  It is the first step to making your model more manageable.

History Blocks

If a History block shows up in the Memory Usage list as a major consumer of memory, check out how many rows are in the history table.  From time to time, I will set a History block up to record more than just 1000 rows (default).   I might want to set it up for 10,000 rows or more, so I can see all items that traveled through it.  If I ever forget to reset this back down to 1000 rows or even delete the History block altogether, it can consume a bit of memory with an excessive row quantity.  I also like to set up the History block so the data is not saved when the model is saved.  Finally, I like to use the temporary History block if I am debugging.  This is the one that dangles off of an item output.  I like to use this one because every so often I can delete them all with a simple right click.

Queue Item Contents and Activity Item Contents

If an Activity or Queue shows up in the Memory block list, check out the Item Contents tab. The Item Contents tab on the Queue and History can get large under various conditions. For example, if you are showing the historical log and have many items have traveled through it across the run, then it does take up a great deal of memory. 

Database Tables \ Log Tables

If a database table shows up in the Memory block list, check out how many records the table contains.  Tables that contain a log of items or events that constantly grow can be pesky at times when it comes to consuming memory.  The log tables are useful for debugging and analysis; however, when doing really long runs for multiple replications, they can become huge.  I suggest you add a flag as a user input that has the capability to turn off capturing the detailed log table in situations where the table isn’t necessary. The flag is useful when you are performing a large number of replications for a study, and you are really only interested in the high-level results and not a detailed log.

.BAK file

By default, the model makes a backup copy of itself every time you save the model.  This file has the same name but has an extension of .bak instead of .mox.  The model will use this when you use the function File \ Revert Model to revert the model to the last save version.  The backup file isn’t necessary for any other reason.  For older versions of the model, you can definitely delete their .bak.  If you don’t want to create the .bak file in the first place, there is an option that you can set to turn it off.  This can be set in the Edit\Options\Misc tab.  By the way, when you email your model to others or you make a backup copy of the model, the .BAK file does not need to be included.