OM 1.16 fails to read XML parameters from input file

[john.pye@…]

Hi there,

In SolarTherm (​https://github.com/SolarTherm/SolarTherm), we make direct use of the compiled model executable ('C runtime') to run our simulations, and we pass modified parameters into each simulation by writing customised XML input files for each run-case.

However we have noticed that since Modelica 1.16, we have not been able to use this feature successfully. It is as though OM 1.16 is *not reading* the XML file provided.

We've written a test case to show the problem This case works correctly with OM 1.14 but fails with 1.16.

​https://github.com/SolarTherm/SolarTherm/blob/master/tests/TestXMLParameter.py

This code basically compiles a simple model file, then modifies the XML input file and runs the simulation. If the updated value from the XML file has been successfully used, the test passes. If not, the test fails.

Details on running this case are here:
​https://github.com/SolarTherm/SolarTherm/wiki/Building-SolarTherm

I tested with Ubuntu 18.04.

Note that there is ANOTHER bug with OM 1.16 which also impacts on successful running of this test, which I will report separately.

Cheers
JP

[Francesco Casella]

I'm not sure I understand all the details of your Python code, but what I read ​from here is

		self.pxml.write_par(par_n=['SM', 't_storage'], 
                                    par_v=[self.sm, self.t_storage],one=False)
		sim.compile_sim(args=['-s'])
		sim.simulate(start=0, stop=10, step=0.1)		

and the code of the sim.compile_sim method read

	def compile_sim(self, n_jobs=(1 + mp.cpu_count()//2), args=[]):
		"""Compile model source code into a simulation executable."""
		sp.check_call(['make', '-j', str(n_jobs), '-f', self.makefile_fn] 
			+ args)

It seems to me that you are building the simulation executable after setting the XML file. The standard make process generates also the XML file based on the default values in the Modelica code, so it seems that your modified XML gets overwritten. Or does args='-s' mean you only call the simulation executable? Are you using the makefile generated by OMC or one of your own making?

I would also suggest that you first try a manual test where you change one parameter in the XML file, run the executable from the command line and report what happens.

Thanks!

[John Pye <john.pye@…>]

Hi Francesco -- no, as far as I recall, the compile_model step is the one that creates the XML file (runnning omc), so that is happening before creating the modified XML file.

As I mentioned, this works perfectly with OM 1.14 (and possibly also 1.15) but clearly fails with 1.16. I believe that we traced the problem down to the model executable failing to use values from the XML file, for some reason (perhaps this pathway for getting parameters into a simulation has been deprecated, but there was no warning about that that I saw).

[John Pye <john.pye@…>]

To answer your other question: yes, we are using the Makefile provided by omc.
I think that the compile_sim with args='-s' is simply asking make to run silently, to suppress a bunch of output.
Relevant code is here: ​https://github.com/SolarTherm/SolarTherm/blob/6868395cac31d2f6edc34ccee6a4a4756196909d/src/python/solartherm/simulation.py

[Martin Sjölund]

If I modify t_storage in that example's init.xml, it works fine for me (at least using the tagged SolarTherm 0.2). It should work as long as isValueChangeable = "true" (which might not be the case if some flags for evaluating parameters are set, but by default it should work).

[John Pye <john.pye@…>]

Thanks! OK, we will look into the isValueChangeable = "true" issue. Perhaps we are trying to set values that cannot be set.

[Andreas Heuermann]

I'll close this issue for now since it was inactive for a long time.
If the problem is still valid please try with the newest version of omc and reopen this ticket.

[john.pye@…]

I believe this error is still there (and hey, it was only two months ago that we received the feedback! a bit too zealous, I feel?)

[Andreas Heuermann]

Sorry, maybe I was a bit quick to close the issue. I can't test your problem on my machine, since I'm using Ubuntu 20.04 inside WSL 2 and I can'T install all python packages.
I did not succeed to open the SolarTherm example Reference_2 (getting missing units for year) in OMEdit as well.

---

So I did a quick test with helloWorld

model helloWorld
  Real x(start=1,fixed=true);
  parameter Real a=0;
equation
  der(x) = a*x;
end helloWorld;

and run

omc -s helloWorld # --> sources and helloWorld_init.xml is generated
# Change value of a to 1 in helloWorld_init.xml
make -f helloWorld.makefile # --> executable is generated, helloWOrld_init.xml will not be changed
./helloWorld

And when I look at the result file the value of a was changed. To be sure I tried ./helloWorld -override=startTime=0.0,stopTime=2.0,stepSize=0.1 as well.

When I make a e.g. protected the start value can still be changed but is marked as isValueChangeable = "false" and the changed value for a is ignored.

But looking into your model I can't see why t_storage shouldn't be changeable. Maybe because of the unit h?

Can you construct an example that is using only MSL and doesn't need SolarTherm isntalled? So only using a bash script or something.

[Francesco Casella]

I'm not sure why this was scheduled for 1.16.1. We need to release that anytime soon, because it contains several critical bugfixes.

@John, if this is critical for you to have in a release, please reset the milestone to 1.16.1, otherwise we'll try to fix it in 1.17.0 and you'll get that in the nightly build.

[john.pye@…]

This is critical for us! Without it, we are forced to keep using trusty ole v. 1.14.x. All of your other fine efforts will be for nowt!

However, I cannot change the milestone, because I don't have privileges here.

[Francesco Casella]

Brought it back.

If you could reproduce the issue with MSL only, that would make things easier, I understand both @sjoelund.se and @AnHeuermann couldn't reproduce your problem so far, which makes it difficult to fix.

[Francesco Casella]

@john, we really need to proceed with 1.16.0 release. We still cannot reproduce this issue, did you check the status with the isValueChangeable attribute?

[Adrian Pop]

I also tried this on an Ubuntu 18.04 with the latest nightly and when I run TestXMLParameter.py i get:

START
(0, 'SM', 2.8)
(1, 't_storage', 9)
/usr/bin/../lib/x86_64-linux-gnu/omc/libModelicaMatIO.a(ModelicaMatIO.o): In function `Mat_VarDelete':
(.text+0x1d51): warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'
assert            | warning | The following assertion has been violated at time 0.000000
|                 | |       | false
assert            | warning | Nominal variable violating min/max constraint: 573.15 <= tankHot.medium.T <= 873.15, has value: 300
assert            | warning | The following assertion has been violated at time 0.000000
|                 | |       | false
assert            | warning | Nominal variable violating min/max constraint: 573.15 <= receiver.medium.T <= 873.15, has value: 300
assert            | warning | The following assertion has been violated at time 0.000000
|                 | |       | false
assert            | warning | Nominal variable violating min/max constraint: 573.15 <= tankCold.medium.T <= 873.15, has value: 300
assert            | warning | The following assertion has been violated at time 0.000000
|                 | |       | false
assert            | warning | Nominal variable violating min/max constraint: 573.15 <= powerBlock.T_in <= 873.15, has value: 300
assert            | warning | The following assertion has been violated at time 0.000000
|                 | |       | receiver.medium.T >= 573.15 and receiver.medium.T <= 873.15
assert            | warning | Variable violating min/max constraint: 573.15 <= receiver.medium.T <= 873.15, has value: 296.15
assert            | warning | The following assertion has been violated at time 0.000000
|                 | |       | tankCold.medium.T >= 573.15 and tankCold.medium.T <= 873.15
assert            | warning | Variable violating min/max constraint: 573.15 <= tankCold.medium.T <= 873.15, has value: 563.15

('     :', 'sm ', 't_storage')
('model:', 2.8, 9.0)
('input:', 2.8, 9)
('xml  :', '2.8', '9')
.
----------------------------------------------------------------------
Ran 1 test in 4.686s

OK

So it seems everything works fine. I will try with 1.16 as well.

[Francesco Casella]

Retargeted to 1.18.0 because of 1.17.0 timed release.

[Francesco Casella]

Ticket retargeted after milestone closed