open TELEMAC-MASCARET The mathematically superior suite of solvers

p iangle
to see the value of iangle
as the segfault occur on the line where there is IPID.EQ.DDPID(I,IANGLE) I suspect the value of iangle out of the definition of DDPID but I could be wrong...

PS: a quick reference of gdb is available here

That reference for gdb is very nice, clear, and useful, big thank you!

And in regards to my calculation, here is the equation and the values when it stopped calculating




Thanks for your help, Cristoph

Great
You should now find why alpha = NAN

Regards

Hi Christoph

Apparently, I still can't figure out what went wrong with my model. As a little reminder, the problem always occurs at this line in my dragfo subroutine:

IF(IPID.EQ.DDPID(I,IANGLE))THEN

which IANGLE comes from the following equation:

IANGLE=INT(ALPHA+0.5D0)

This is where it gets interesting. Because ALPHA is NaN. ALPHA, comes from the following equation:

ALPHA=-ATAN2(UTECY,UTECX)*RTD

When I traced It back, UTECY and UTECX are also NaNs. Tracing back, UTECs equations are:

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 checked DET1, DET2, DET3, and SURDET, they all have valid numbers.
However, when I run the command "P U%R(N1)""P U%R(N2)""P U%R(N3)" and their V%R counterparts in gdb, the result for each variable is 0. This is the last tracing of NaN which no longer shows NaN. Thus I figure there is something wrong with the UTECX and UTECY equation.

But I don't know what this implies. Does -ATAN2 not work when both values of the variables are zero? Does the angle or the speed of velocity at this particular time step not calculatable?

Also, the value of IANGLE is exaggeratingly big with -2147483648.

I need your guidance and insights on this one.
Thank you.

Hi
There is probably something to check with the function ATAN2 as the result when both parameter are 0 is probably compiler dependant...
Nevertheless, if UTEC and VTEC are already NaN, this becomes more obvious if all individual components are not NaN...
As debugger is not really easy to use step by step if the problem occurs late in the execution, you could add some prints in the code to allow you to understand where is the problem.
Regards

Hi,

So, I tried to look deeper into the code, and before this line:

ALPHA=-ATAN2(UTECY,UTECX)*RTD

was this line:

IF(NCSIZE.GT.0)UTECX=P_DSUM(UTECX)
IF(NCSIZE.GT.0)UTECY=P_DSUM(UTECY)

Somehow I think this overwrites the value of UTECX and UTECY from the equation with the determinants.

So, I tried to change the line into:

IF(NCSIZE.GT.0)UTECX=UTECX
IF(NCSIZE.GT.0)UTECY=UTECY

And the calculation works! (at least for now it has passed the previous error time step and keeps going). I think it has something to do with P_DSUM. Is it for when I run the calculation in parallel?

Thanks.

Those lines exists for parallel computation to ensure a share of information between all processors. You should think that the partitioning of the domain could separate the area where the dragfo is added.
This probably also means that you doesn't take care of parallelism in your programmation. This is sometimes quite complex but necessary as the partitioning varies according to the number of processors...
Hope this helps

Yes I have made a mistake. Deleting P_DSUM does not make my model run smoothly. It ended after 1 day and 11 hours of simulation. Longer than usual probably due to a variable I changed.

I do not know where to trace down the problems but I will try my best to trace the NaN. Thanks Christophe. I appreciate your huge help to make me understand the situation.

Hi,

sorry to come back here again. After looking deeper, the problem narrows down to these lines:

!

---

! APPLY THE DRAG FORCE OF THE TEC
!

---

DO I = 1,NTEC
UTECX=0.D0
UTECY=0.D0
PTEC(I) = 0.D0
IF(IPID.EQ.TECPID(I))THEN
N1=IKLE%I(TECELEM(I))
N2=IKLE%I(NELEM+TECELEM(I))
N3=IKLE%I(2*NELEM+TECELEM(I))
!
SURDET=1.D0/((X(N2)-X(N1))*(Y(N3)-Y(N1))-
& (X(N3)-X(N1))*(Y(N2)-Y(N1)))
!
DET1=(X(N3)-X(N2))*(YTEC(I)-Y(N2))
& -(XTEC(I)-X(N2))*(Y(N3)-Y(N2))
DET2=(X(N1)-X(N3))*(YTEC(I)-Y(N3))
& -(XTEC(I)-X(N3))*(Y(N1)-Y(N3))
DET3=(X(N2)-X(N1))*(YTEC(I)-Y(N1))
& -(XTEC(I)-X(N1))*(Y(N2)-Y(N1))
!
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
END IF

I think the problem is that at some point in the simulation, the code has a problem extracting the value from the vertices (I am not really sure whether it occurs in the N1, N2, or N3 lines, or in the UTECX and the UTECY lines). What condition usually causes this problem? Is it possible to be caused by the model? because judging from previous discussion the code seems fine.

For deeper understanding, the problem usually occurs when the direction of the current is switching (from South to North and vice versa) and there's a swirling motion in the current.

Thanks

If this code works for some time steps, I would say there is a lot of chances that the problem comes from the model itself...
As it works, this mean N1, N2 and N3 are well identified and there is no changes for that along the simulation...
The only potential problem could comes from a value of U or V which could be a NaN if the solving step at previous time step gives this result...
You could probably investigate by just running hot start simulation for few time step starting just before the crash occurs...
With a result at all time step and some print this could highlight what is possibly a bug or a problem in the model.
Hope this helps