Save Project from a procedure

Dear @oomse 

I noticed the issue and have corrected the article you quoted. It was still using an old case management style in AIMMS.

Please use the following procedure to save your case. You can also go back to the article which has been updated.

Procedure SaveCase {
    Arguments: (sp_CaseName);
    Body: {
        ! Save the case in the folder "data".
        if not DirectoryExists( "data" ) then
            DirectoryCreate("data");
        endif ;
        CaseFileSave( "data\\" + sp_CaseName, AllIdentifiers );
    }
    StringParameter sp_CaseName {
        Property: Input;
    }
}

Thank you!

What is the problem you are trying to solve with this? Normally, your model will not be changed via code, but only changes you make in the model tree (with the exception of runtime libraries with MEF, but those are not saved anyway when you save the project).

Not sure if something like this would be possible natively with AIMMS. Can only think of very hacky solutions that might not be very robust

Thank you both for your reactions and effort. As a workaround, I think that I will indeed create a message that tells us to save the project. Thank you for the tip! Unfortunately, I do not have access to the ideas page (while logged in).

@oomse, I'm wondering whether those continuous model changes are mostly wrt data that you store as part of the model, or whether you actually change the model formulation that often (which I find much harder to imagine).

In the first case, I would argue that in most cases non-static data should not be part of the model, but should be stored separately (file, database, CDM). This would give you a way to store model state without having to save the model on every run.

In the second case, if you have to change the model formulation that often, isn't it possible, and much more natural, to make the model formulation more data driven? In that case, changes in model behavior are driven by changes in data (potentially by following different branches in your code through if-then-else constructs if need be). Also, you can have a superset of variables and constraints, only a subset of which you can actually include in your optimization model. This allows for another method to make an optimization model with e.g. different objectives in a data driven manner. By making your model formulation data driven, you end up in the first case again. 

Lastly, it seems your current approach is to set apart a version of the model with every case that you run. I would argue that the use of a version control system like git would be a much better approach. Not only will it save a tremendous amount of space (as you only have to add a reference to the model revision that you were using to run the case, which can be easily recreated on disk if need be), but using version control also gives you a very convenient way to later inspect what actually changed in between revisions. Using CDM for storing your data, will also give you version control on your data, allowing you to create a new scenario, based on some previous revision of your data.