I don't know why, but the addition of DeltaVVI in the init file makes the initialisation less robust in my test case even if IdConv0Pu is 0 for all generators. I.e. it fails to initialise with DeltaVVI, but initialise smoothly (all derivatives close to 0 at t=0) without.

I don't know why, but the addition of DeltaVVI in the init file makes the initialisation less robust in my test case even if IdConv0Pu is 0 for all generators. I.e. it fails to initialise with DeltaVVI, but initialise smoothly (all derivatives close to 0 at t=0) without.

We had initially some problems simulating the test case in the Dynawo library OpenModelica example. Did you try modifying the solver's parameters?

I retried with

and

<dyn:localInit parFile="init.par" parId="1"/>

<set id="1">
    <par type="INT" name="mxiter" value="300"/>
    <par type="DOUBLE" name="fnormtol" value="1e-2"/>
    <par type="DOUBLE" name="initialaddtol" value="0.1"/>
    <par type="DOUBLE" name="scsteptol" value="1e-2"/>
    <par type="DOUBLE" name="mxnewtstep" value="100000"/>
    <par type="INT" name="msbset" value="0"/>
</set>

which didn't solve the issue.

It works with some values of msbset (1, 2, 4) in my test case, but not all (0, 3, 5, 10 do not work).

This is very weird, with the same dynawo distribution (https://github.com/FredericSabot/dynawo/releases/tag/32_TEXAS), the issue mentioned above occurs on my laptop but not in my server.

(I also have a separate issue where KINSOL fails following the occurrence of a fault but only on the server, not on my laptop.)

This is very weird, with the same dynawo distribution (https://github.com/FredericSabot/dynawo/releases/tag/32_TEXAS), the issue mentioned above occurs on my laptop but not in my server.

(I also have a separate issue where KINSOL fails following the occurrence of a fault but only on the server, not on my laptop.)

@rosiereflo Do you have any idea why this would occur?

This is very weird, with the same dynawo distribution (https://github.com/FredericSabot/dynawo/releases/tag/32_TEXAS), the issue mentioned above occurs on my laptop but not in my server.
(I also have a separate issue where KINSOL fails following the occurrence of a fault but only on the server, not on my laptop.)

@rosiereflo Do you have any idea why this would occur?

This looks like a side effect of small differences caused by the machine, but going from a succesfull init to a crash is quite surprising. DOes it happen with the initial solver setup?

What do you mean by initial solver setup?

Here are the logs of the first test case with default solver parameters

2024-10-08 11:05:26 | INFO | starting local initialization
2024-10-08 11:05:26 | INFO | -----------------------------------------------------------------------
2024-10-08 11:05:26 | WARN | five consecutive steps have been taken that satisfy a scaled step length test
2024-10-08 11:05:26 | WARN | local initialization of model 344_PV_2 failed
2024-10-08 11:05:27 | INFO | end of local initialization
2024-10-08 11:05:27 | INFO | -----------------------------------------------------------------------
2024-10-08 11:05:27 | INFO | 
2024-10-08 11:05:27 | INFO | -----------------------------------------------------------------------
2024-10-08 11:05:27 | INFO | starting global initialization
2024-10-08 11:05:27 | INFO | -----------------------------------------------------------------------
2024-10-08 11:05:27 | INFO | Algebraic mode change at t = 0
2024-10-08 11:05:27 | WARN | five consecutive steps have been taken that satisfy a scaled step length test
2024-10-08 11:05:27 | ERROR | KINSOL fails to solve the problem ( DYNSolverKINAlgRestoration.cpp:394 )

and with lvlFilter="DEBUG"

2024-10-08 11:06:02 | DEBUG | starting local initialization of model 344_PV_2
2024-10-08 11:06:02 | WARN | five consecutive steps have been taken that satisfy a scaled step length test
2024-10-08 11:06:02 | WARN | local initialization of model 344_PV_2 failed
2024-10-08 11:06:02 | DEBUG | local initialization of model 344_PV_2 ended successfully
[...]
2024-10-08 11:06:02 | INFO | Algebraic mode change at t = 0
2024-10-08 11:06:02 | DEBUG | initial condition iteration 0
2024-10-08 11:06:03 | DEBUG | call of SolverReInit i.e. a new symbolic and numerical factorization will be performed
2024-10-08 11:06:03 | WARN | five consecutive steps have been taken that satisfy a scaled step length test
2024-10-08 11:06:03 | ERROR | KINSOL fails to solve the problem ( DYNSolverKINAlgRestoration.cpp:394 )

Could you please try to run the testcase in with a debug compilation so that all the details are provided? Thanks

I have attached the logs and test case run in Debug mode.

test_case.zip

The case has been run with my_fork/32_Texas +
/* External loop /
PRef0Pu = PFilter0Pu;
UdFilter0Pu = UFilterRef0Pu - KffIdPcc0Pu - DeltaVVId0;
QRef0Pu = QFilter0Pu;
UqFilter0Pu = - Kff*IqPcc0Pu - DeltaVVIq0;

in GridForming_INIT.mo

The relevant part in the local initialisation failure is

2024-10-08 15:34:31 | WARN | local initialization of model 344_PV_2 failed
2024-10-08 15:34:31 | DEBUG | error > 0.0001 : F[2] = -2.26553e+08 equation $DAEres13 = control.IdConv0Pu * control.XVI0 + control.IqConv0Pu * control.RVI0 - control.DeltaVVIq0
2024-10-08 15:34:31 | DEBUG | error > 0.0001 : F[10] = -172515 equation $DAEres5 = cos(control.Theta0) * converter.u0Pu.im + (-sin(control.Theta0)) * converter.u0Pu.re - converter.UqPcc0Pu
2024-10-08 15:34:31 | DEBUG | error > 0.0001 : F[8] = -118722 equation $DAEres7 = sin(control.Theta0) * converter.u0Pu.im + cos(control.Theta0) * converter.u0Pu.re - converter.UdPcc0Pu
2024-10-08 15:34:31 | DEBUG | error > 0.0001 : F[7] = -20652.1 equation $DAEres8 = 100.0 * (sin(control.Theta0) * converter.i0Pu.re - cos(control.Theta0) * converter.i0Pu.im) / converter.SNom - control.IqPcc0Pu
2024-10-08 15:34:31 | DEBUG | error > 0.0001 : F[13] = -14212.4 equation $DAEres2 = 100.0 * ((-cos(control.Theta0)) * converter.i0Pu.re - sin(control.Theta0) * converter.i0Pu.im) / converter.SNom - control.IdPcc0Pu
2024-10-08 15:34:31 | DEBUG | error > 0.0001 : F[4] = 8065.62 equation $DAEres11 = max(control.IConvSquare0Pu - control.IMaxVI ^ 2.0, 0.0) - control.DeltaIConvSquare0Pu
2024-10-08 15:34:31 | DEBUG | error > 0.0001 : F[5] = 8.11746e+08 equation $DAEres10 = control.IqConv0Pu ^ 2.0 + control.IdConv0Pu ^ 2.0 - control.IConvSquare0Pu
2024-10-08 15:34:31 |
 DEBUG | local initialization of model 344_PV_2 ended successfully

There is more info in the logs for global initialisation.

ok this is a strong divergence. I will need to investigate further, could you please send me the details on how to reproduce (maybe on dynawo-rte mail) so that I can help you with this? thanks

The full test case is attached to my previous message. To run it, you can checkout the branch and replace the first four equations in dynawo/sources/Models/Modelica/Dynawo/Electrical/Controls/Converters/GridFormingControl_INIT.mo

PRef0Pu = PFilter0Pu;
UdFilter0Pu = UFilterRef0Pu - KffIdPcc0Pu - DeltaVVId0;
QRef0Pu = QFilter0Pu;
UqFilter0Pu = - Kff*IqPcc0Pu - DeltaVVIq0;

(The release https://github.com/FredericSabot/dynawo/releases/tag/32_TEXAS does not include the -DeltaVVI and is more robust.)

The test case is quite big, however it seems there is only one problematic generator in this case, so I don't think I can easily provide a smaller one.

And to get it to initialise properly, you can try to change the msbset value in init.par to other values: (1, 2, 4) work, but (0, 3, 5, 10) do not.

ok thanks let me take a quick look to see if I can help with this :)

I'm sorry I was not able to reproduce the divergence on my machine. what is the OS of the server used?

The issue occurs on my Ubuntu 22.04.5 LTS x86_64 laptop (virtual machine). I will create a distribution with the -DeltaVVi change and try to reproduce on the server (I cannot compile directly on the server).

I have been able to reproduce the issue (with distribution https://github.com/FredericSabot/dynawo/releases/tag/nightly) on a Fefora-based server.

Server nic5

cat /etc/os-release 
NAME="Rocky Linux"
VERSION="8.7 (Green Obsidian)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.7"
PLATFORM_ID="platform:el8"

And same with a CentOS

Server hercules

cat /etc/os-release 
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"

Find and replace all

<par type="DOUBLE" name="control_KpVI" value="0.67"/>

with

<par type="DOUBLE" name="control_KpVI" value="10.67"/>

(or even 1.67) causes a second GFM generator to fail to initialise (343_PV_1, close to 344_PV_2) in my machines. This might help you reproduce the issue on your side. This also indicates that the issue might be related to the virtual impedance control.

We had initially some problems simulating the test case in the Dynawo library OpenModelica example. Did you try modifying the solver's parameters?

@joyelfeghali Upon further analysis, it seems like there are many "direct paths" (i.e. paths without any time delay) between the input and outputs of the GFM control block. Although the model is somewhat isolated from the grid via the filter and dynamic transformer model, dont' you think this could lead to issues for the solver (e.g. following large changes like for a fault)?

Hi, I'm sorry no matter the different attempts I was not able to reproduce this on my laptop. I will try to use a docker and let you know

Hello, just to make sure, because I have updated the nightly distribution since last time: the release where the issue occurs is https://github.com/FredericSabot/dynawo/releases/tag/32_Texas_With_DeltaVVI. The test case is still https://github.com/user-attachments/files/17294253/test_case.zip