51) OMNI:DELETE TABLE

GRTMPS offers several ways to temporarily remove data which is not currently needed, whether it is just for the wrong season or catalyst age, or a new option not yet ready, or a temporarily unavailable resource.  You can comment things or deactivate them at locations particular locations or in certain periods.  If you are familiar with the spreadsheet data entry system, you will probably know that you can overwrite or replace tables with OMNI:DATA,MODIFY or OMNI:DATA commands. 

But sometimes it just more useful to obliterate a whole set of information that you don’t want to have active.  It might just be more convenient – to simplify debugging, to save memory and processing time, or to avoid warning messages.   There are some situations, however, where the existence of a particular data table, or the presence of a row or column, even if empty, is going to trigger certain processing in the matrix generation that make it difficult to set up the model correctly.   This is particularly likely to come up when you are combining models together to make a corporate or global multi-location one, or where you receive models from others and want to configure your own case data (such as when doing planning for your share of a joint venture.)

The easiest way to completely remove a set of data is to delete the table that contains it.  Here is how to do that using commands from our OMNI modelling language, which can be used in GRTMPS data files.

 

 
Each command must begin with OMNI:  (That’s a colon at the end.)  Everything should be in upper case.  No extra spaces.
MODE,IMMEDIATE is an instruction to process the commands as they are read, instead of compiling them.
FS and FS,END mark the beginning and end of the set of commands.
DELETE TABLE table_name WHEN TABLE table_name(,)  is doing the work. Then WHEN part ensures that there is no error message if the table doesn’t exist.  That's a comma in the parentheses.  (If you are used to working with the database input system, you may need to do some research to determine the table names.)   

 

These example commands are from the KNOCKOUTS.xlsx file used in our Corporate Demo model.

 

The sub-models for Refinery 11 and Refinery 33 come first to provide location specific information – such as the process unit data.  The Corporate Model database is at the end, so that the information in it has the last word.  However, as the databases are always read as successive modifications, some unwanted information from the sub-models could be left in.  So the “KNOCKOUTS” file is put in the penultimate position to remove them.  It is particularly critical to take out TABLE 001.0, active location group, as this table is always assumed to have only one entry – which would, otherwise, be the group code that is active in the first sub-model. 

You can also use OMNI:DELETE TABLE….. in Case Generator files.     We have a set of cases for testing the error trapping.   So we can be sure, for example, that any table based model that does not include a TABLE 001.0 to nominate an active location group will continue to abort in every new version of GRTMPS.  (If everyone switched to the database system, by the way, we could take a lot of this stuff out of the code.)   I’m not sure if there is an application for OMNI:DELETE in case generator for normal use – so if you think of one, please let me know.

If you are interested in more information about what to look out for when combining models, there are some notes in the g5 Knowledge Base – and there are also some useful papers in the on-line Haverly user conference archives.