Solutions Analyst Bruno Pereira shares some tips on organizing and updating the Optimize section in Woodstock. The same strategies can be applied to the Outputs, Yields or Areas sections.
Hi Woodstock clan!
I would like to share with you some features and codes in Woodstock that I wish I had known more about when I was a Woodstock user and working as a Planning Analyst.
So, when the model is all set and data is ready, it’s time to let the magic begin!
You run the model once, twice… likely several times. For each of these runs, you are also likely making small changes to the optimize section in order to find a great solution (and hopefully not an infeasible one!) or to compare scenarios.
While many changes are still just tests and not worth transferring to the template, there is always the chance that you forget to, or just don’t want to, commit them to the template.
Let’s also consider the added complexity if the model you are working on has a large optimize section with multiple include files and full of upper and lower bound constraints based on allowed percentage variation. In this case, if you need to update these constraints and files, the easiest and fastest way to do so is by using Integrator.
In this scenario, my problems came when I was updating the model, since my template did not contain all my changes and tests, and due to the number of constraints and FOREACH loops, I would often get lost when choosing the ones I wanted to bring to my optimize section.
Of course, there are many ways to overcome this issue.
My preference (hence the topic of this tech tip) is to use REGIONS and {$beginupdateregion} / {$endupdateregion}.
REGIONS
Regions are used to control the use of sections of the template during model updates with Remsoft Integrator.
In order to use regions, the user must declare *REGIONS .\filename.dbf in the Control section. The .dbf file declared will be created automatically by the application if it successfully finds regions in the template.
There are different types of regions:
- BEGINREGION
The code bounded inside of this region can be switched on or off.
- BEGINRADIOREGION
Always used with multiple BEGINRADIOREGION blocks. Only one can be switched on.
- BEGINALWAYSONREGION
Since this region is always on, it is used to organize the grouping.
Let’s see some examples:
Optimize section in the template:
Updating the model:
Result of the update:
Regions are convenient and help to organize and select what needs to be updated from the template.
The problem is that if something is not in the template, it will get lost when the section is updated.
So how can we fix that?
{$beginupdateregion} and {$endupdateregion}
The concept is very simple and straightforward. The statement must be in the Woodstock section. Integrator will write in between the begin/end codes everything that is in the template AND will NOT erase anything that is outside of it.
Let’s see an example:
As you can see, nothing that was outside the {$beginupdateregion}/{$endupdateregion} got deleted while all template regions and include files were brought to the optimize section.
Note that the include file for MIP_Variables is not within the begin/end statements. However, it still gets updated (see red arrow) because I added the loop that creates and updates it to the template, even though the *INCLUDE code is located only in the section.
Why is that?
*VARIABLE must be in the top of the section, while the constraints are in the bottom. The problem here is that it is not possible to have more than one begin/end statement. Therefore, it was just a strategy to still get my MIP_Variables file updated while locating the *INCLUDE in the right place.
~~~
Now that you know the concept and how to use these codes in the Optimize section, you can go ahead and try it in other sections too. Perhaps they can be useful in the Outputs, Yields or Areas.
What do you think?
