free surface initial displacement initialization

[st268]

Hello,

Using v4, on a mac (El Capitan).

I have been trying to set an initial free surface displacement in cs_user_initialization as recommended by Martin Ferrand in http://code-saturne.org/forum/viewtopic ... 3&start=10. I have attached the subroutine. Everything compiles but I get an error in the calculation stage, listing attached for details.

The error is:

Criterion 5: Guilt by Association:
Number of bad cells detected: 0 --> 0 %

Computing geometric quantities (0.0246 s)

Extended neighborhood reduced by non-orthogonality
--------------------------------------------------

Size of complete cell-cell connectivity: 78804
Size of filtered cell-cell conectivity: 0
78804 connections removed, for a ratio of 0 % used

ALMAX = 0.58512E+00 (Characteristic length )
ALMAX is the cubic root of the domain volume.

SIGSEGV signal (forbidden memory area access) intercepted!

Call stack:
1: ? ? (?)
2: ? ? (?)
3: ? ? (?)
4: ? ? (?)
End of stack

From another forum post (http://code-saturne.org/forum/viewtopic.php?f=2&t=1731) Yvan thought a similar error was due to not calling intprf but I think that is specific to that forum post being about the atmospheric module which Im not using. Anyone have any ideas where this error might be from?

Thanks in advance!

[Yvan Fournier]

Hello,

I would recommend first adding a "debug" build to Code_Saturne.
Details are provided in the installation manual, but relative to your previous install, here are short instructions:

- cd to the build directory , where you previously re-ran the configure, make, ... sequence (where you added "--disable-shared" to the configure command), or better yet, create a side-by-side, directory, with the same name + "_debug" postfix.

- run the same "configure" command you previously ran, adding "_dbg" (for example) ath the end of the "--prefix=..." option, and adding "--enable-debug" to the list of options

- run "make clean && make && make && make install"

Once this is done, you will have a second, "instrumented build" (about 3x slower, but with more checks). If you added "_dbg" to the prefix (as in the above recommendation, but you can choose another name), add it to the line containing the path in the "runcase" file, and run the code again.

The code will probably crash again, but with the debug build, you should have the names of files in the stack trace, which will make pinpointing/understanding/debugging the error much easier, and we can iterate again from there (so the extra 10-20 minutes for the secondary reinstall will be worth it).

Regards,

Yvan

[st268]

Hi Yvan,

Thanks once again for the detailed response! I built the debug build as you suggested (made an empty directory, ran the configure command from within it, ran make clean, make, make, make install; changed uncase accordingly) but sadly it still won't tell me more information in the stack trace, though it does have more rows of ''?' this time:

Extended neighborhood reduced by non-orthogonality
--------------------------------------------------

Size of complete cell-cell connectivity: 78804
Size of filtered cell-cell conectivity: 0
78804 connections removed, for a ratio of 0 % used

ALMAX = 0.58512E+00 (Characteristic length )
ALMAX is the cubic root of the domain volume.

SIGSEGV signal (forbidden memory area access) intercepted!

Call stack:
1: ? ? (?)
2: ? ? (?)
3: ? ? (?)
4: ? ? (?)
5: ? ? (?)
6: ? ? (?)
7: ? ? (?)
8: ? ? (?)
9: ? ? (?)
10: ? ? (?)
End of stack

This was the configure command I used:
/Users/Charlie/Developer/code_saturne-4.0.3/configure --prefix=/Users/Charlie/Code_Saturne/4.0.3/code_saturne-4.0.3/arch/Darwin_x86_64_dbg --with-hdf5=/usr/local/Cellar/hdf5/1.8.15 --with-cgns=/usr/local/Cellar/cgns/3.2.1_1 --with-med=/usr/local/Cellar/med/3.0.8 --with-metis=/usr/local/Cellar/metis/5.1.0 --with-scotch=/usr/local/Cellar/scotch/6.0.4_1 --with-libxml2=/usr/local/Cellar/libxml2/2.9.2 PYTHON=/usr/local/bin/python --disable-static CXX=/usr/bin/c++ CC=/usr/local/bin/mpicc FC=/usr/local/bin/gfortran --disable-shared --enable-debug

And the runcase contents:
#!/bin/bash

# Ensure the correct command is found:
export PATH=/Users/Charlie/Code_Saturne/4.0.3/code_saturne-4.0.3/arch/Darwin_x86_64_dbg/bin:$PATH

# Run command:
\code_saturne run

Is it another mac thing do you think?

[Yvan Fournier]

Hello,

This might be another mac thing, I'm not sure. The debug build probably still has more info, so the next stage would be to run it through a debugger (if one is installed), but I might avoid walking through this (which can be done through the GUI in the upcoming version 4.2) checking your code:

in your initialization,

allociate(lstelt(ncel))

should be called before the first getfbr call.

In any case, I forget to remind you (and everyone else) that when you have a crash and are using user subroutines, the first step in debugging is to check if running without the user files avoids the crash ...

Regards,

Yvan

[st268]

Hello,

I will try and set it up as best I can with the GUI then. In the meantime I fixed the error you noticed in the subroutine and the error in listing is now:


/Users/Charlie/Developer/code_saturne-4.0.3/src/alge/cs_multigrid.c:2780: Fatal error.

algebraic multigrid [Mesh Velocity]: divergence after 1 cycles:
initial residual: nan; current residual: nan

Which seems like that fixed the error with my initialisation subroutine and I'm now onto the next error. Progress I suppose! I think I need to fix the mesh size/time step to fix this one.

Thanks once again for your help!

[st268]

Hello,

I have greatly reduced my mesh resolution and time-step in the hope of stopping my divergence error but neither seems to have any effect. In fact I have now used the same settings as a PhD student at Manchester used and still no better so now I am thinking it is back to how I have setup my initial mesh displacement.

Does anyone know if I am setting up my initial mesh displacement correctly? My user_s_initialisation subroutine is attached again. Depending on where I look either depale or disale is used to specify mesh displacement from initial mesh position. Which one should I be using? Though I have tried my subroutine as it stands with both and neither work for me. I can find help and examples of setting up a time dependent mesh displacement in usalcl but not for specifying an initial mesh displacement at time zero, is a different variable used for this?

As always, thanks in advance.

[st268]

subroutine attached

[Yvan Fournier]

Hello,

Do not forget the forum usage recommendations. With only your user subroutine, It's hard to guess what to improve.

Regards,

Yvan

[st268]

Sorry, here is everything! Sloshing is the case directory. I'm using v4.0.3.

Thanks and happy Friday!

[Yvan Fournier]

Hello,

The crash seems to occur very early. In any case, I would recommend one of 2 options to help debug this:

- build a debug version (as mentioned in my previous post), which will make debugging easier with added instrumentation

- try to use the GUI, to reduce the number of user files. In any case, with or without the GUI, use as little possible user files, simplifying your setup, and adding them again progressively, to find which one is (probably) causing the issue.

Also, if you have the valgrind tool installed on your Mac, run the code using Valgrind (check either the GUI or cs_user_scripts.py for an example). It has high overhead, so can be used only with small to medium meshes, but even for a non-debug build, you may get some additional info (and with a debug build, you get the file/line numbers where problems are detected)

Regards,

Yvan