open TELEMAC-MASCARET The mathematically superior suite of solvers

I see.

I will run the model from the start until a few time steps before the error occurs to begin the hot start simulation.

Also, for additional information, the distance of the reference velocity from the turbine matters.

For instance, when I set the reference velocity to 25 meters in front of the turbine, The simulation managed to run for 11 hours before crashing. If I set it to 100 meters, the model runs for 35 hours before crashing. This got me confused as to where to start the troubleshooting process.

I also have tried a few meshes with different element sizes and densities and still provides no solution so far.

Sounds logical to see an influence of the reference velocity points...
Let's see the results of your investigation with the hot start...
Regards

Hi,

I have finished the calculation and there are some notable things.
First, these are the important parameters of the model:

Time Step : 0.5
Start Date : 4 January 2022
Start Time : 08:00:00

Discretization in Space : 11;11
Solver : 1
Solver Accuracy : 1.E-4

With a cold start, the simulation runs for a little over 10 H 30 MIN (08:00 - 18:30) before it crashes.

Then I performed another calculation to act as a PREVIOUS CALCULATION FILE. Using the same settings, I ran the model for 9 H 30 MIN which succeed with no problem. Then I used the result to perform a hot start calculation.

At first, I ran the hot start model using a standard win7gfors configuration. The model runs for another 13 H 30 MIN (a total added time with the previous calculation of 23 H 00 MIN) before it crashes.

Then, I run the same hot start model using the debug win7gforsdbg configuration using gdb for debugging purposes. The calculation stopped at 1 H or 10 H 30 MIN of total running time with the previous calculation. The same amount of time step with the cold start calculation in the beginning.

The error message is the same as what I have seen for the past few weeks:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000406257 in dragfo (fudrag=..., fvdrag=...)
at D:\0_modelling\telemacfiles\ntt_turbine\28_dbg\user_fortran\dragfo_4a.f:381
381 IF(IPID.EQ.DDPID(I,IANGLE))THEN

With UTECX and UTECY is still -nan

What values should I look to investigate this error?
Thanks

Hi
You could try to see if you could make a hot start at 10:20 or 10/25 to have only few time step before crash as the goal is to print all the time step in the result file without generating a huge file...
Once it's OK, you could also add some prints in dragfo to check which value gives you NaN...

Hope this helps

Hi

Yes, I am currently running for the 10:20 as you suggested then will analyze the result.

In the meantime, I changed some lines in the dragfo subroutine. This is how it used to written:

UTECX=U%R(N1)*DET1*SURDET+
& U%R(N2)*DET2*SURDET+
& U%R(N3)*DET3*SURDET
UTECY=V%R(N1)*DET1*SURDET+
& V%R(N2)*DET2*SURDET+
& V%R(N3)*DET3*SURDET

I changed those lines to:

U1=U%R(N1)
U2=U%R(N2)
U3=U%R(N3)
V1=V%R(N1)
V2=V%R(N2)
V3=V%R(N3)
!
UTECX=U1*DET1*SURDET+
&U2*DET2*SURDET+
&U3*DET3*SURDET
UTECY=V1*DET1*SURDET+
&V2*DET2*SURDET+
&V3*DET3*SURDET

to see the direct value of the U%R and V%R. As I ran them in gdb and printed U1 to V3, they were all NaNs. Perhaps the answer will become clearer once the 10:20 hot start calculation has finished.

If U1 to V3 are Nan this mean the previous solving step crash...
Let's see with the hot start and the all time step results...

Hi,

To conclude my progress so far,

Initially, I run my hot start from 17:30 (9 H 30 MIN) from the initial calculation time). The model fails at around 10 H 30 MIN simulation time using win7gfors. However, when I run the model using win7gforsdbg, it continues running until 23 H.

Then, as you suggested, I run my hot start from 18:20:00 (10 H 20 MIN from initial calculation time), and it runs smoothly until around 07:00:00 the next day (23 H from initial calculation time). I don't know what makes this difference but it does not stop at 10 H 30 MIN.

However, the simulation, no matter what configuration I used or the initial time step of the second hot start, seems to fail consistently at 23 H (07;00;00) after the initial calculation time. So I do this scheme:

1. 08;00;00 - 17;30;00 (9 HR 30 MIN - win7gfors)
2. 17;30;00 - 06;45;00 (13 HR 15 MIN - win7gfors)
3. 06;45;00 - 07;03;00 (18 MIN - win7gforsdbg) - SIMULATION CRASHES

And the result is the same. U1 to V3 is a NaN.

So should I extract the velocity values in the TEC location using BlueKenue for every vertices to check for the problem?

Hi
First you should run the latest simulation with printout period (graphic and listing) to 1 in order to have all informations in the result file and the listing.
Then you could look in the result if the values of U and V are Nan every where or just locally and also pick some info in the listing to see if this si a problem of convergence or just a crash...
In a second time, you could run with some additional printing or with gdb to try to understand why the U and/or V values became equal to NaN... There is probably a problem with the computed value of the dragfo at the previous time step...

Hope this helps

Hi,

Following your suggestion, I ran my simulation 5 minutes prior to crashing. After running it again using 0.5 s time step, setting both printout periods to 1, and set the value of U and V to be printed during the simulation, this is the result.








It is horribly full of NaNs . I do not know the values of the previous time step since I can't scroll further up but it looks like it is full of NaNs with a few valid values. What do you think might cause this problem? What measures would you suggest to analyze the source of the problem?

Thanks.

use the -s option to have a full listing file...