Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#5619 closed defect (fixed)

Homotopy-based initialization does not use updated parameter values when re-simulating

Reported by: BuettR51 Owned by: Karim.Abdelhak
Priority: blocker Milestone: 1.16.0
Component: Initialization Version: v1.13.2
Keywords: Cc: adeas31, Karim.Abdelhak, lochel

Description

It is not currently possible to obtain results for updated parameters in compiled models that require homotopy-based initialization. Instead, homotopy-based initialization always uses the default parameter values that the model was compiled with.

Please consider the following test case of a modified van der Pol oscillator:

model TestInitialization "Simple model to demonstrate homotopy bug"
   parameter Real A = 0.8;
   Real x;
   Real xPrime;
   Real mu;

initial equation
   x = 0.2;
   der(x) = -1;
equation
   der(x) = xPrime;
   mu = homotopy(0.1*x*der(x) + 0.1*der(xPrime), 0.1*der(x));
   der(xPrime) + mu*A*(x*x - 1)*xPrime + x = 0;
end TestInitialization;

Steps to reproduce the problem:

  1. Simulate TestInitialization using –homotopyOnFirstTry.
  2. Set the parameter A to 0.1 by using the Variables Browser, modifying Model_init.xml, using –override, or using –overrideFile.
  3. Re-simulate the compiled model with -homotopyOnFirstTry using any method, then examine the results. The value of A will not be updated and the results will be the exact same as if they were run using A = 0.8. (If using the Variables Browser to re-simulate, the displayed value of A will be 0.1, but plotting it will show that it is actually 0.8 instead).

Performing the same steps without -homotopyOnFirstTry results in the parameter being updated as expected.

This behavior is present in more complicated models as well. It practically prohibits obtaining useful results from large-scale parameter sweeps where conventional initialization is likely to fail.

Thank you.

Change History (10)

comment:1 Changed 5 years ago by casella

  • Cc adeas31 Karim.Abdelhak lochel added
  • Milestone changed from Future to 1.14.0
  • Owner changed from lochel to AnHeuermann
  • Priority changed from high to blocker
  • Status changed from new to assigned

@AnHeuermann, could you please have a look? This should be solved for 1.14.0 if possible.

comment:2 Changed 5 years ago by AnHeuermann

I don't think I can solve this until Monday, since my priorities are on a different project at the moment.
I will have a look into it at the end of next week.

comment:3 Changed 5 years ago by casella

OK, no problem

comment:4 Changed 5 years ago by casella

  • Milestone changed from 1.14.0 to 1.15.0

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2.

This issue, previously marked as blocker for 1.14.0, is rescheduled to 1.15.0

comment:5 Changed 4 years ago by casella

  • Milestone changed from 1.15.0 to 1.16.0

Release 1.15.0 was scrapped, because replaceable support eventually turned out to be more easily implemented in 1.16.0. Hence, all 1.15.0 tickets are rescheduled to 1.16.0

comment:6 Changed 4 years ago by casella

@AnHeuermann, can we fix this for 1.16.0?

Last edited 4 years ago by casella (previous) (diff)

comment:7 Changed 4 years ago by Karim.Abdelhak

I changed something for homotopy resimulate in #6001, this could already be fixed. I will test tomorrow.

comment:8 Changed 4 years ago by AnHeuermann

  • Owner changed from AnHeuermann to Karim.Abdelhak

I'm busy with FMI at the moment. But maybe it is already fixed by @kabdelhak

comment:9 Changed 4 years ago by Karim.Abdelhak

  • Resolution set to fixed
  • Status changed from assigned to closed

I tested with -override and it works perfectly fine. Adeel tested the other stuff for #6001, everything is fixed!

comment:10 Changed 4 years ago by casella

Thank you folks!

Note: See TracTickets for help on using tickets.