Usage of three-phase Aron sensor got problematic last December 2019

[massimo ceraolo]

Consider attached models InvSW and InvSWaron. They differ only for an Aron sensor; however, the first model runs correctly with recent builds, while the second one causes run-time messages (below) and fails.

Since both worked well last summer, I tried to understand when this issue was introduced.
I checked that

• with OM 1.15.0-dev 35 (6th of last December) both models work well
• with PM 1.16.0-dev-63 (should have been generated just before 15th of December) only InvSW runs correctly.

Error message (first rows):

The default linear solver fails, the fallback solver with total pivoting is started at time 0.000000. That might raise performance issues, for more information use -lv LOG_LS.
Matrix singular!
Failed to solve linear system of equations (no. 269) at time 0.000000, system is singular for U[2, 2].
The default linear solver fails, the fallback solver with total pivoting is started at time 0.000000. That might raise performance issues, for more information use -lv LOG_LS.
Matrix singular!
Failed to solve linear system of equations (no. 269) at time 0.000000, system is singular for U[2, 2].
The default linear solver fails, the fallback solver with total pivoting is started at time 0.000000. That might raise performance issues, for more information use -lv LOG_LS.
Matrix singular!
Failed to solve linear system of equations (no. 269) at time 0.000000, system is singular for U[2, 2].
The default linear solver fails, the fallback solver with total pivoting is started at time 0.000000. That might raise performance issues, for more information use -lv LOG_LS.
Failed to solve linear system of equations (no. 48) at time 0.000000, system is singular for U[2, 2].
Matrix singular!
Failed to solve linear system of equations (no. 269) at time 0.000000, system is singular for U[2, 2].
The default linear solver fails, the fallback solver with total pivoting is started at time 0.000000. That might raise performance issues, for more information use -lv LOG_LS.
Matrix singular!
Failed to solve linear system of equations (no. 269) at time 0.000000, system is singular for U[2, 2].
The default linear solver fails, the fallback solver with total pivoting is started at time 0.000000. That might raise performance issues, for more information use -lv LOG_LS.
Matrix singular!
under-determined linear system not solvable!
Error solving linear system of equations (no. 269) at time 0.000000.
Solving linear system 269 fails at time 1.36931e-009. For more information use -lv LOG_LS.
The default linear solver fails, the fallback solver with total pivoting is started at time 0.000000. That might raise performance issues, for more information use -lv LOG_LS.
Matrix singular!
Failed to solve linear system of equations (no. 269) at time 0.000000, system is singular for U[2, 2].
The default linear solver fails, the fallback solver with total pivoting is started at time 0.000000. That might raise performance issues, for more information use -lv LOG_LS.
Matrix singular!
The initialization finished successfully without homotopy method.
Failed to solve linear system of equations (no. 269) at time 0.000000, system is singular for U[2, 2].

[Francesco Casella]

@ceraolo, 1.15.0 was forked in October (if I am not mistaken) and only a few commits made to the main development branch (i.e., 1.16.0-dev) were cherry picked and put there, to avoid the kind of unstable behaviour you are experiencing.

If you want to use bisection to identify the offending commit, you should stay on the 1.16.0-dev branch.

@adrpo, I checked the ​old 1.16.0 nighly builds but they only stretch back to 15 Dec (1.16.0-dev-85. Are older versions available somewhere?

[Francesco Casella]

@ceraolo, I would also suggest you to check with the debugger the contents of that linear system with the two versions that you mentioned - note that the id could change, you should look for the variables involved.

[massimo ceraolo]

@ceraolo, 1.15.0 was forked in October (if I am not mistaken) and only a few commits made to the main development branch (i.e., 1.16.0-dev) were cherry picked and put there, to avoid the kind of unstable behaviour you are experiencing.
I know

@adrpo, I checked the ​old 1.16.0 nighly builds but they only stretch back to 15 Dec (1.16.0-dev-85.

That's why I mentioned 1.15!

[Francesco Casella]

1.15.0 only has a few of the commits of 1.16.0

[Adrian Pop]

We had to remove older builds as the server was running out of disc space.

[Francesco Casella]

Maybe it could be worth keeping one for each week or something...

[massimo ceraolo]

I want to underline that the difference between the two models is that in the aron version there is just one more sensor. Therefore this model should in principle have no additional solving difficulty.

[Francesco Casella]

See comment:2

[massimo ceraolo]

Replying to casella:

See comment:2

Sorry, I don't understand what you are exactly asking there.

I know that the developers are very busy, but I'm not sure I'm able to help their activity better than I did.
As you see, I tried to find the latest version in which the model worked and the earliest in which it did not. Unfortunately, 1.16 night builds did not go deep enough in the past.

However, I could try to do what you suggest with the debugger, in case the instructions are step-by-step, or whatever I'm able to understand.
But probably it is more efficient for the developers to try to with the enclosed file themselves the tests they deem most useful when they find time.

[Francesco Casella]

Replying to ceraolo:

However, I could try to do what you suggest with the debugger, in case the instructions are step-by-step, or whatever I'm able to understand.

• In Simulation Setup |Simulation Flags, turn on LOG_LS_V. This enables verbose logging of the linear solver
• Simulate the model with the debugger (green arrow with the blue bug button).

In the log you'll see something like

Error solving linear system of equations (no. 273) at time 0.000000.
Solving linear system 273 fails at time 8.62663e-008. For more information use -lv LOG_LS.
Debug more

If you click on Debug more, the debugger will open at the corresponding linear equation. This was solved by tearing, so a 2x2 system is reduced to a 1x1 system. As you can see, the A matrix turns out to be zero, i.e., the system is singular.

Now what is left to do is to understand why the A matrix has such a value. The linear torn system has these two equations

regular (torn) Cf.i[1] := star2.plug_p.pin[1].i - Rload.i[1]
regular (residual) Cf.i[1] - Lf.inductor[1].i + Rload.i[1] = 0

with torn variable Cf.i[1] and unknown of the residual system Rload.i[1].

The reason why this system is singular is obvious: if you look at the two equations and bring them back to residual form, the coefficients of Cf.i[1] and Rload.i[1] are +1 and +1 in both equations, so you can't solve them for those two variables.

The question now is: where do these two equations come from? We can use the equation operations window in the debugger to answer this question. The first comes from this chain of transformations, starting from the current balance at the start2.plug_p.pin connector and then going through some simplifications and substitutions:

simplify: Cf.plug_n.pin[1].i + Rload.plug_n.pin[1].i + star2.plug_p.pin[1].i = 0.0
substitution: (-Cf.i[1]) + (-Rload.i[1]) + star2.plug_p.pin[1].i
simplify: star2.plug_p.pin[1].i + (-Rload.i[1]) - Cf.i[1] = 0.0
solved: Cf.i[1] = star2.plug_p.pin[1].i - Rload.i[1]

while the second starts from the current balance at the Cf.plug_p.pin connector and then goes through this other chain of transformations:

aronSensor1.plug_p.pin[1].i + Lf.plug_n.pin[1].i + Cf.plug_p.pin[1].i = 0.0
substitution: aronSensor1.plug_p.pin[1].i + Lf.plug_n.pin[1].i + Cf.plug_p.pin[1].i
           -> aronSensor1.plug_p.pin[1].i + (-Lf.inductor[1].i) + Cf.i[1]
simplify: aronSensor1.plug_p.pin[1].i + (-Lf.inductor[1].i) + Cf.i[1] = 0.0
       -> aronSensor1.plug_p.pin[1].i + Cf.i[1] - Lf.inductor[1].i = 0.0
substitution: aronSensor1.plug_p.pin[1].i + Cf.i[1] - Lf.inductor[1].i
       ->     Rload.i[1] + Cf.i[1] - Lf.inductor[1].i

all these steps look legitimate to me, unfortunately the end result turns out to be singular, so there possibly something wrong with how these equations have been combined.

[Francesco Casella]

But now comes the important piece of information: if you compile the model with debug flag -d=stateselection (I'm not sure whether this is set by default in OMEdit, I guess it should, because it's very important information), you get:

Number of states: 5 (Cf.capacitor[2].v,Cf.capacitor[3].v,Lf.inductor[1].i,Lf.inductor[2].i,Lf.inductor[3].i)

and therein lies the rub!

As you can see, the star connection at the bottom right of the diagram causes the three currents to sum to zero. Hence, also the three currents of the Lf inductor are constraind to sum to zero. This structural condition makes the problem index-2.

The ASCC algorithm by Karim should detect this situation, basically by inferring that the three inductors currents and the three currents into the start connection are the same, by suitably combining the current balance equations of the two parallel circuit branches in-between. Then, it should trigger Pantelides' algorithm and the dummy derivatives algorithm, eventually only keeping two of the three inductor currents as state variables.

For some reasons this mechanism doesn't work, so you eventually get a singularity somewhere, as it always happens when you try to solve an index-2 problem without index reduction.

I guess the problem is in the fairly convoluted structure of the Aron sensor, which is somehow not detected by the structural algorithms.

@Karim, would you mind having a look?

[Francesco Casella]

The attached InvSWaron2 model reproduces the issue with a simpler, purely continuous-time circuit.

[Francesco Casella]

See also #5452, we solved similar problems there.

@Karim, it seems though the model was actually working before you committed your ASCC algorithm. I guess it needs some further refinement, and I hope the InvSWaron2 test case is good for this purpose.

[Karim Adbdelhak]

Maybe i am missing something but i built the last version v1.16.0-dev.268+g5d28ab166f from source and ran InvSWaron.mo as well as InvSWaron2.mo and both worked fine.

These were the selected states:

 * Number of states: 5 (Cf.capacitor[1].v,Cf.capacitor[2].v,Cf.capacitor[3].v,Lf.inductor[2].i,Lf.inductor[3].i)       

Furthermore -d=bltdump showed a reasonable index reduction process. Unfortunately i cannot reproduce your problem. Feel free to correct me if i missed a crucial part here!

[massimo ceraolo]

Replying to Karim.Abdelhak:

Maybe i am missing something but i built the last version v1.16.0-dev.268+g5d28ab166f from source and ran InvSWaron.mo as well as InvSWaron2.mo and both worked fine.

These were the selected states:

 * Number of states: 5 (Cf.capacitor[1].v,Cf.capacitor[2].v,Cf.capacitor[3].v,Lf.inductor[2].i,Lf.inductor[3].i)       

Furthermore -d=bltdump showed a reasonable index production process. Unfortunately i cannot reproduce your problem. Feel free to correct me if i missed a crucial part here!

I tried right now on my Work PC and invSWaron worked well, while invSW did not.
I'll repeat it at my home PC this evening to understand better what's going on and will post the results.

[massimo ceraolo]

Since the results change when changing PC, it should be a matter of options.
Therefore I add (options.pdf) screenshots of the options I used for this ticket.
Using these options, OM 1.16-dev-104 (the more recent version I can try by now) runs correctly invSW and does not invSWaron and invSWaron2.
Using the same options OM 1.15-dev 35 runs everything.

[Karim Adbdelhak]

I re-ran some of the stuff and it seems like -d=newInst makes a difference. Quite possibly the old frontend did some simplifications the new one does not which was caught by the reshuffle loops algorithm (which got replaced by ASSC).

I will have a look!

[Francesco Casella]

Replying to Karim.Abdelhak:

I re-ran some of the stuff and it seems like -d=newInst makes a difference. Quite possibly the old frontend did some simplifications the new one does not which was caught by the reshuffle loops algorithm (which got replaced by ASSC).

I 100% agree with this diagnosis :)

I will have a look!

Thanks!

[Francesco Casella]

@ceraolo, I just retried this model with the latest 1.16.0 nightly build.

Now we get a lot of runtime warnings regarding equation system 91, but eventually the simulation reaches the stopTime successfully. Of course all currents and voltages are zero because there is no source in the circuit, so I'm not really sure if this is ok or not, but I'm leaning towards "it's not" because of the following analysis.

Equation system 91, that you can inspect with the debugger, contains the following equations:

91 linear (torn), unknowns: 2, iteration variables: 1
(torn) Cf.i[1] := star2.plug_p.pin[1].i - Rload.i[1]
(residual) Cf.i[1] - Lf.inductor[1].i + Rload.i[1] = 0

The system is a 2x2 linear system, which is solved via tearing. The torn unknown is Cf.i[1], while the iteration variable is Rload.i[1].

There is obviously something wrong in this system, because if you take the torn equation and symbolically substitute into the residual one, the two Rload.i[1] terms cancel out, so obviously the system is singular and cannot be solved for the iteration variable.

I suspect the reason of this failure is that index reduction is not carried out correctly, eventually leading to a structurally singular DAE system.

The selected state variables for this system are:

Cf.capacitor[2].v
Cf.capacitor[3].v
Lf.inductor[1].i
Lf.inductor[2].i
Lf.inductor[3].i

As usual in this kind of circuits, the original DAE is index-2, because the star2 connection constrains the sum of the three phase currents to be zero. As far as I understand, this constraint should propagate over the parallel/series connection of Cf, aronSensor1 and Rload, resulting in the sum of the three Lf.i[j] currents (which are potential states) to also be zero. Conversely, I understand there is really no constraint on on the three capacitor voltages, which can be set independently thanks to the parallel connection with the load. @ceraolo, can you please confirm that?

If that is the case, then there is something wrong in the ASSC algorithm, because it selects one of the three capacitors' voltage as dummy state, instead of one of the three inductors', hence leading to a structurally singular system.

@Karim, would you mind having a look when you have time? I guess this analysis should enable you to figure out what is going wrong quite easily.

[massimo ceraolo]

Replying to casella:

@ceraolo, I just retried this model with the latest 1.16.0 nightly build.

Now we get a lot of runtime warnings regarding equation system 91, but eventually the simulation reaches the stopTime successfully. Of course all currents and voltages are zero because there is no source in the circuit,

Indeed, invSWaron has sources and implements a square-wave inverter. The three Rload voltages are not zero, but I cannot say whether they are or not correct since the simulated time before simulation stops is very small.

so I'm not really sure if this is ok or not, but I'm leaning towards "it's not"

Yes, it IS NOT ok. At least because of the many warnings and Matrix singular messages and because simulations stops at 0.1 ms.

[Francesco Casella]

Replying to ceraolo:

Yes, it IS NOT ok. At least because of the many warnings and Matrix singular messages and because simulations stops at 0.1 ms.

I reproduced the problem with the stripped-down InvSWaron2 model. That has no sources and discrete-time stuff, but it still causes the same index reduction issue. @Karim, I guess it can still be used to debug the problem, they you can test the original model once it has been fixed.

[Karim Adbdelhak]

I am really confused by this case. In general i think i get what is happening: Only algebraic loops are considered for ASSC, since they are the only ones that can be algebraically singular. For one part of the model it works perfectly fine:

######################################################                   
 LinearIntegerJacobian sparsity pattern: Original                                                
######################################################                                                              
(scal_idx|arr_idx|changed) [var_index, value] || RHS_EXPRESSION                 
(5|5|false):    [17|1] [29|1]       || RHS: Lf.inductor[2].i               
(2|2|false):    [17|-1] [29|-1]     || RHS: -star2.plug_p.pin[2].i                               
                                                                                                                    
######################################################                          
 LinearIntegerJacobian sparsity pattern: Solved                                                                                                    
######################################################                                           
(scal_idx|arr_idx|changed) [var_index, value] || RHS_EXPRESSION                                                     
(5|5|false):    [17|1] [29|1]     || RHS: Lf.inductor[2].i                      
(2|2|true):     EMPTY ROW         || RHS: Lf.inductor[2].i - star2.plug_p.pin[2].i
                                                                                                 
[ASSC] The equation: star2.plug_p.pin[2].i + (-Rload.i[2]) - Cf.i[2] = 0.0                                          
[ASSC] Gets replaced by equation: 0.0 = Lf.inductor[2].i - star2.plug_p.pin[2].i

And then subsequently correctly differentiated by index reduction:

------------------2------------------                                           
Constraint equation to be differentiated:                                
0.0 = Lf.inductor[2].i - star2.plug_p.pin[2].i                                                   
Differentiated equation:                                                                                            
0.0 = der(Lf.inductor[2].i) - der(star2.plug_p.pin[2].i)   

But for the other loop (the one you posted is quite identical, all indices are just 1 instead of 2) this does not happen. In the regular system it is not a loop, only in the initial system it is. Therefore it is not considered for ASSC. I guess i will have to also include the initial equations when analyzing the strong components, but right now i do not know how to do that efficiently. Also it might be a mistake in general that we do not consider initial equations for index reduction (up to debate?).

Also it seems like these equations are used for simulation and i do not really know why. Based on the matching for simulation that should not be necessary.

Now comes the weird part: Using the old frontend prevents this error (what?). I do not really know what happens here, i have to consult some frontend people for this.

Also activating --preOptModules+=resolveLoops (while still using the new frontend) fixes the problem. This is an algorithm that does quite the same thing as ASSC but less efficient and less strict. But it finds the equations differently and in this particular case that works.

[Francesco Casella]

Replying to Karim.Abdelhak:

I guess i will have to also include the initial equations when analyzing the strong components,

I don't get this. Initial equations are not relevant w.r.t. the structure of the model and its index.

Also it might be a mistake in general that we do not consider initial equations for index reduction (up to debate?).

I don't really think we should. Initial equations are only added to determine the initial values of states and fixed = false parameters. They can't change structural properties such as the index. Do I miss something?

Also it seems like these equations are used for simulation and i do not really know why. Based on the matching for simulation that should not be necessary.

I need to look at this more carefully, but unfortunately right now I don't have enough time.

Also activating --preOptModules+=resolveLoops (while still using the new frontend) fixes the problem.

@ceraolo, you can use this as a temporary fix to avoid the regression while we figure this issue out.

[massimo ceraolo]

@ceraolo, you can use this as a temporary fix to avoid the regression while we figure this issue out.

I'll do, thanks.

[Karim Adbdelhak]

Replying to casella:

I don't really think we should. Initial equations are only added to determine the initial values of states and fixed = false parameters. They can't change structural properties such as the index. Do I miss something?

Well maybe i phrased it incorrectly. The basic structure of these loops is really easy:

model M
 Real a,b;
 Real x,y;
equation
 f1(der(x), a, ...);
 f2(der(y), ...);
 x - a - b = 0.0;
 a + b - y = 0.0;
end M;

ASSC adds up eq (3) and (4) and replaces one of them by the result which is x = y. That now is an higher index problem that index reduction can handle.

Since this a three phase system the structs occur multiple times, once for each phase. The problem here is that only in the second phase both x and y seem to be states. For the other phases both of them are already removed (i guess by remove simple equations) to be a dummy and we end up with something like:

model M
 Real a,b;
 Real x,y;
equation
 f1(x, a, ...);
 f2(y, ...);
 x - a - b = 0.0;
 a + b - y = 0.0;
end M;

The basic difference is, that this seems to not be an algebraic loop for simulation, but an algebraic loop for initialization where a and b have to be solved in eq. (3) and (4). That is probably due to the way the values are initialized.

I do not really know what that exactly means... I assume that those equations should have been considered during index reduction when x and y where removed and they should also have been differentiated to make the initialization consistent here.

[Francesco Casella]

I'm not sure I get this, in the second model M the first argument of f1 is now x instead of der(x). Why did this change?

Also, I'm not really sure why there are constraints involving only two current states, instead of three, nor why on some phases they are both gone as states (not just one).

Could it be that we have three phases with two inductors in series on each phase (whereby one current should be a dummy state), plus a star connection which forces one more current to become a dummy?

Also, I'm always a bit confused by removeSimpleEquations doing the index reduction. Are we sure this can never cause problems downstream when Pantelides' algorithm is invoked?

[Francesco Casella]

Retargeted to 1.17.0 after 1.16.0 release

[Francesco Casella]

Rescheduled to 1.18.0

[Karim Adbdelhak]

I now understand what the problem is and why we need ASSC for initialization. Short explanation on what ASSC usually does and what it can do for initialization.

Usually if there are coupled algebraic variables or states like so:

  der(x) = sin(time);
  der(y) = cos(time) + a;

  2*a + 2*b + c + x = 10;
  a + b + y = 5;
  a + b + c = 0;

The ASSC algorithm figures out that there is the following hidden constraint equation:

 x - y = 5.0;

Replacing one equation of the loop with this equation triggers index reduction which would go undetected without it. It transforms an analytical to a structural singularity. This does only seem to be relevant for systems where index reduction is applied, which is not true in general. It needs to applied on any system that is not known in prior to be balanced and regular, which includes the initial system. We could look at the presented system and assume that one of the equations belonging to the loop (3-5) are only part of the initial and not the simulation problem. In that case ASSC would not find it analyzing the simulation system, but it would still be needed for initialization since it changes the way the states need to be initialized. Unhandled this leads to the singular matrices at hand.

Resolving this once again is a problem with the order of operations in the old backend. Reshuffle Loops and the Balancing of initialization was done before and independent of Matching. Balancing the initial system should happen just like index reduction, during the matching process. It is just another way of resolving singularities. This method is implemented in the new backend, but would need too much restructuring in the current backend. In the old backend it worked with reshuffle loops, because it was handled independently, but doing that is just double the work. ASSC needs to happen before the balancing of initialization and I could extract ASSC to be handled outside of matching, but it would just do a matching itself... unnecessary work. Here are the current pipelines in the old and new backend:

Old Backend Simulation (good!):

0. (Reshuffle Loops)
1. Matching

1.1 ASSC
1.2 Index Reduction -> back to 1.

Old Backend Initialization (bad!):

0. (Reshuffle Loops)
1. Prebalance Initialization
2. Matching

2.1 ASSC

New Backend Simulation & Initialization (good!):

1. Matching

1.1 ASSC
1.1 Resolve Singularities -> back to 1.

Long story short: Problem identified, working on something to make it work for the old backend without breaking or reworking everything. The current backend fails with a warning for index reduction where it should just balance the initial system.

[Francesco Casella]

Replying to Karim.Abdelhak:

I now understand what the problem is and why we need ASSC for initialization. Short explanation on what ASSC usually does and what it can do for initialization.

Usually if there are coupled algebraic variables or states like so:

  der(x) = sin(time);
  der(y) = cos(time) + a;

  2*a + 2*b + c + x = 10;
  a + b + y = 5;
  a + b + c = 0;

The ASSC algorithm figures out that there is the following hidden constraint equation:

 x - y = 5.0;

Replacing one equation of the loop with this equation triggers index reduction which would go undetected without it. It transforms an analytical to a structural singularity.

So far, so good.

This does only seem to be relevant for systems where index reduction is applied, which is not true in general. It needs to applied on any system that is not known in prior to be balanced and regular, which includes the initial system.

I'm not sure I get this. My understanding of the matter was the following:

• you analyze the dynamic equations, if matching fails you try index reduction and add dummy derivatives (ASSC fits here)
• you build the initialization system by adding initial equations to the index-reduced dynamic equations, and by adding states and fixed = false parameters as unknowns, then redo the matching and sorting, since the causality can be completely different
• in case of high-index reduction and overdetermined initialization problem, you apply some tricks to figure out if there are some redundant but consisten initial equations that can be removed

Is this what the old backend does? I guessed so, but maybe I am wrong.

We could look at the presented system and assume that one of the equations belonging to the loop (3-5) are only part of the initial and not the simulation problem.

I'm sorry, I really do not understand why you should apply ASSC to the intializiation problem. You only apply it to the set of dynamic equations, and in case there are hidden state constraints, you handle them with ASSC and index reduction. Then (and only then!) you add the initial equations to form the initialization problem, and redo matching and sorting again.

Resolving this once again is a problem with the order of operations in the old backend. Reshuffle Loops and the Balancing of initialization was done before and independent of Matching.

Maybe this is not optimal.

Balancing the initial system should happen just like index reduction, during the matching process.

Again, I don't get this. There is no index reduction in the initalization problem, it is just a set of algebraic equations, no distinction between states, derivatives, variables, and fixed = false parameters, they should all be treated in the same way. But the initialization problem should be formulated on the index-1 DAE, not on the original system.

Do I miss something?

[Karim Adbdelhak]

I am currently working on a minimal model to best represent the problem that can occur for initialization!

[Francesco Casella]

OK, I can't wait to see it :)

[Francesco Casella]

@Karim, could you please proceed with the plan you explained during the devmeeting, so we can complete the UniPi DFD #6280?

I understand the plan for the time being is to reactivate reshuffle loops, because it has mostly similar effects as the ASSC algorithm, but they do not overlap 100%.

Possibly with some flag to limit the size of systems reshuffle loops is applied?

[Francesco Casella]

@ceraolo, the fix to this issue is finalized in ​PR 7454. It should be merged in the nightly build anytime soon, you can follow the progress from the PR page.

Thanks for your support!

[massimo ceraolo]

I checked with Today's nightly (dev-289), using this ticket's attachments, and the issue is still there.

[Francesco Casella]

That's because the nightly build pipeline was stalled, so you were using an older version.

The issue was fixed by ​PR 7454. I just tried the latest nighly build v1.18.0-dev-295-gc5f80b95fd and it works fine on both examples.