Problem using file created on older version - Stochastic mapping for units

[alisonk103]

Describe your problem

I am working on updating a model that was created older versions of SpineOpt/Toolbox and am running into "MethodError: no method matching...." when SpineOpt is attempting to set the variable_unit_flow upper bounds. This model makes use of stochastic scenarios, with 4 separate forecasts for a number of the node/unit parameters, where each of the forecasts consists of a different time series. It is very similar to the system described in #1042, which seems to have run into similar errors.

When updating to the latest version I did the following:

1. Upgrade project popup - selected yes

2. Backup and upgrade input/output databases from revision 989fccf80441 to 91f1f55aa972 - selected okay
   

3. Altered specifications of Run SpineOpt to have "upgrade = true"

The key error that pops up once I have done the above is:

I am wondering if the fact that the data being passed is "::SpineInterface.Map{Symbol, SpineInterface.Timeseries{Float64}}" instead of "::SpineInterface.Call" is an error on my side (either in the upgrading or data input in the first place) or if it is pointing out a unit/node that isn't supported for a stochastic scenario map. Currently there are maps on the following entity classes/parameter types:

• node : demand
• unit : unit_availability factor
• unit__to_node : unit_capacity

I would really appreciate any help that anyone could provide!

Attach your model as a JSON file (encouraged)

average4_original_notworking.json
average4_upgrade_notworking.json

What versions are you using?

SpineOpt: v0.10.2
SpineInterface: v0.15.2
SpineToolbox: v0.9.6
Julia: v1.11.1

[tarskul]

I can't remember what the solution was to other issue that you referred to. But I've checked your json file and compared it to a newer json file. The only thing that seemed a bit off to me was ""index_name": "x"". I removed that and uploaded it to the database again, but the error stayed the same. Maybe there are indeed migration issues. But I'm not sure where to start looking from here (other than rebuilding the case), so I don't have an immediate solution for you.

If I come up with something, I'll try again, but for now I'm unsure. If you have been able to try other stuff and get a new clue, please let us know.

[alisonk103]

Hi Tarskul,

Thanks for replying. I've also been unable to solve the issue, or to come up with any new ideas that work. I did get the same file working when there is only one time series for each parameter, so I'm pretty sure the issue is with the timeseries maps. I'm leaving it for now and moving on, but I appreciate your help!

[tarskul]

It is unfortunate that we were not able to resolve this issue. I'm afraid that the only way we can get a new clue is when someone tries to implement it from scratch in the new version. But I don't see that happen any time soon, so I'm closing this issue.

[alisonk103]

Hi Tarskul,

I've been able to get the model working by creating different alternatives for the time series in the maps, and removing maps altogether from the model. (I also had to remove some fix_ratio_out_in constraints that were incorrect, so it's slightly different from the version above). I am wondering if there is a capability at all for SpineOpt to evaluate maps of time series with the stochastic framework? If so, is there any documentation for implementing it? The documentation only includes a map of constant values, and I've been unable to find maps of timeseries in any of the discussion posts etc.

[tarskul]

There is no other material than the documentation. But more tutorials are planned. The reason why it takes so long to add these is that we need to do these tutorials between other tasks. To speed things up, we invite people who are able to figure it out to send in their small models that we can directly add them to the tutorials.

You can also dig in the unit tests but I admit that is not always so clear and easy.

[alisonk103]

I understand, thank you regardless for the help!

[DillonJ]

It's possible that the changes that @manuelma made to improve the performance of the model didn't take into account that bounds may be stochastic maps. Or rather, if the unit_capacity value is a map, then it shouldn't be implemented as a simple bound. Hopefully @manuelma can help