Opened 6 years ago

Last modified 3 years ago

#4898 new defect

The variableFilter option of the simulate() API does not filter parameters and constants

Reported by: casella Owned by: somebody
Priority: high Milestone:
Component: Command Prompt Environment Version:
Keywords: Cc:

Description

In the Scripting API there are several commands, in particular simulate(), that have a variableFilter input, which accepts a regex to specify which variables should be saved.

Unfortunately, no matter what I put in the regex, all the parameters of the model are always saved.

It is true that parameter do not take much space in the result file, as they only have one or two time points. On the other hand, large structured models can have a lot of parameters with very long names, so the part of the result file that contains their name strings can have a significant size.

Is this a bug or a feature?

Change History (8)

comment:1 Changed 6 years ago by lochel

This is the expected behaviour. Not sure if it is actually a good idea to always put all parameters into the result file. So maybe it should be changed.

Another option would be to have a flag to control if also the parameters should be filtered or not.

A third option – and slightly more complicated – would be to add two filtering strategies that can be combined: 1) Filtering by type/kind, e.g. outputs, states, algebraic, iteration variables, … 2) Filtering by regular expressions on the variable names, i.e. variableFilter.

comment:2 follow-up: Changed 6 years ago by casella

I'm not really sure that always putting all parameters is a good idea, what is the rationale behind that? If the idea is, there is little storage involved, then also parameter-dependent variables should be included. But I don't think that would be a good idea either.

I would suggest that the regex filter applies to all variables and parameters.

I like the idea of having an additional mechanism to select the variable kind. That would in fact come in quite handy to generate reference data.

comment:3 in reply to: ↑ 2 Changed 6 years ago by sjoelund.se

Replying to casella:

I'm not really sure that always putting all parameters is a good idea, what is the rationale behind that? If the idea is, there is little storage involved, then also parameter-dependent variables should be included. But I don't think that would be a good idea either.

Parameter-dependent variables should be handled in the same way as parameters, yes. They're treated in the same way in the result-file after all.

I would suggest that the regex filter applies to all variables and parameters.

I like the idea of having an additional mechanism to select the variable kind. That would in fact come in quite handy to generate reference data.

It might be more flexible than the current approach at least: emit protected or not.

comment:4 Changed 6 years ago by casella

  • Milestone changed from 1.13.0 to 1.14.0

Rescheduled to 1.14.0 after 1.13.0 releasee

comment:5 Changed 5 years ago by casella

  • Milestone changed from 1.14.0 to 1.16.0

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2. This issue is rescheduled to 1.16.0

comment:6 Changed 4 years ago by casella

  • Milestone changed from 1.16.0 to 1.17.0

Retargeted to 1.17.0 after 1.16.0 release

comment:7 Changed 4 years ago by casella

  • Milestone changed from 1.17.0 to 1.18.0

Retargeted to 1.18.0 because of 1.17.0 timed release.

comment:8 Changed 3 years ago by casella

  • Milestone 1.18.0 deleted

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.