Sub-routine calling rasize: MEMLA2

[Fabio89]

Running CS I have this error:

------------------------------------------------------------------------
/opt/saturne-2.0.2/installer/ncs-2.0.2/src/base/cs_base.c:815: Fatal error.

Sub-routine calling rasize: MEMLA2

Memory needed in ra (number of reals): 1167650

available: 1125120

----> Define rasize to a value at least equal to 1167650 reals).

Call stack:

1: 0x7fd13d183b25 <rasize_+0xc5> (libsaturne.so.0)
2: 0x7fd13d477747 <memla2_+0x2e7> (libsaturne.so.0)
3: 0x7fd13d162b87 <caltri_+0x5397> (libsaturne.so.0)
4: 0x7fd13d13d9e3 <cs_run+0x843> (libsaturne.so.0)
5: 0x7fd13d13dcc5 <main+0x1f5> (libsaturne.so.0)
6: 0x7fd1398dcc4d <__libc_start_main+0xfd> (libc.so.6)
7: 0x40a359 <> (cs_solver)

End of stack
------------------------------------------------------------------------

Can anyone help me?

Best Regards,

Fabio

[Yvan Fournier]

Hello,

Just increase the memory available in the "memory management" section of the GUI, or in the "ustbr" user subroutine at the end of the usini1.f90 user subroutine.

Regards,

Yvan

[Fabio89]

Hi Yvan,

to increment my real array using the subroutine usini1.f90, can I only write somthing like this?

!==========================================================================
! 1. Size of macro arrays ia and ra :
!==========================================================================

Size of main integer work array 'ia'

longia = 0

Size of main real work array 'ra'

longra = 1167650

because I didn't find "ustbr" in usini1.f90.

Or using the GUI (on which I'm more skillful), in Memory Management --> Real Array , can I only write in Main Real Work Array = 1167650 [Memory needed for my case in ra (number of reals)]?

What are the meanings of:
-Number of cells whit HALO
-Number of Interior Faces
-Number of Boundary Faces
Always interested to learn something more.

Thanks,

Fabio

[guingo]

Hi Fabio,

in fact, it is "ustbtr", not "ustbr" (it is the last routine in usini1.f90); if I were you, I would set maybe longra to 2000000 and see what happens.

Best regards,
Mathieu

[Fabio89]

Hello Mathieu,

In this days I made several tests of my project, changing mesh parameters, but at last I had the same error in "Memory needed for my case in ra (number of reals)" with:

MEMLA1 = 318019
MEMPHY = 338243

so I tried setting:

Main Real Work Array = 320000
Number of cells whit HALO = 340000

and simulation run for a lot of miutes (otherwise previous tests in which it suddenly stopped).
But at last I had this error:

SIGFPE signal (floating point exception) intercepted!

Call stack:
1: 0x7fc5082d9ca6 <+0x7ca6> (libm.so.6)
2: 0x7fc5082f69d2 <acos+0x12> (libm.so.6)
3: 0x7fc50ab5cbb9 <uslabo_+0x18f9> (libsaturne.so.0)
4: 0x7fc50ab24173 <lagcel_+0x166f> (libsaturne.so.0)
5: 0x7fc50ab58d98 <lagune_+0x35f8> (libsaturne.so.0)
6: 0x7fc50a846193 <caltri_+0x59a3> (libsaturne.so.0)
7: 0x7fc50a8209e3 <cs_run+0x843> (libsaturne.so.0)
8: 0x7fc50a820cc5 <main+0x1f5> (libsaturne.so.0)
9: 0x7fc506fbfc4d <__libc_start_main+0xfd> (libc.so.6)
10: 0x40a359 <> (cs_solver)
End of stack

Could you help me?
I really don't know how solve this issue!

Thank you so much for your time

Fabio

[Fabio89]

Do anyone know this problem?
I really don't know what I can do to solve it.
I Ask your help please!

Best Regards,

Fabio

[Yvan Fournier]

Hello,

The call stack shows the error is in calling acos, in user function uslabo.

This is a user subroutine, and you have a "floating point exception" error in it, so you need to fix your subroutine.

Best regards,

Yvan

[Fabio89]

Hi Yvan,

can I solve my problem using the GUI?
How can i do in this case?

Thanks,

Best Regards

Fabio

[Yvan Fournier]

Hello Fabio,

I'm not a specialist regarding the Lagrangian module, so I can't help you much regarding this. uslabo is an optional routine, so I guess that if you are using it, you need it, but you'll need to adapt it to avoid the crash (check where acos is used, and add a test to check if its arguments are "out of bounds" for example, printing where things go wrong, and working up from there).

Also, did you check that the calculation runs correctly without the Lagrangian module (correct mesh, reasonable tie step). Add the Lagrangian model only once you are sure, and optional features after that, to get a better understanding of what causes the crash. Otherwise, it is hard to guess what is going wrong, so we can't help you much.

You can also post your data here if it is very small, but we are starting validation of version 3.0, so we might test it on 3.0, but will only have time to run minor tests on 2.0.

I'll let Mathieu add any other recommendations, as he is the expert for the Lagrangian module.

Best regards,

Yvan

[guingo]

Hi Fabio,

sorry for the late reply, I have been quite busy recently, fortunately Yvan provides you with good advice.

Indeed, the acos function is called only once in the uslabo function; in the calculation of the impacting angle:

937 if (iangbd.eq.1) then
938 vnorm = ettp(ip,jup) * ettp(ip,jup) &
939 + ettp(ip,jvp) * ettp(ip,jvp) &
940 + ettp(ip,jwp) * ettp(ip,jwp)
941 vnorm = sqrt( vnorm )
942 ang = ettp(ip,jup) * surfbo(1,kface) &
943 + ettp(ip,jvp) * surfbo(2,kface) &
944 + ettp(ip,jwp) * surfbo(3,kface) &
945 / surfbn(kface) &
946 / vnorm
947 ang = acos(ang)
948 parbor(kface,iang) = parbor(kface,iang) + ang*tepa(ip,jrpoi)
949 endif

Maybe you can try to first, deactivate the calculation of the boundary statistics to check if calculation runs correctly without this impacting angle calculation. If the calculation seems OK, activate the boundary stats again and try then to bypass the lines I quote by for instance, replacing the first test by something like

if (iangbd.eq.12345) then

to make sure you do not enter this part of the routine. And as Yvan said, if the data are small, post them here and I will have a look.