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).
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!
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 …
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:
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.
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?
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)
I set it up with the GUI and only the cs_user_initialisation subroutine and it crashes with the same error so I guess it is in that subroutine! I have posted on an older post where I was discussing setting up a standing wave with Martin Ferrand (http://code-saturne.org/forum/viewtopic.php?f=2&t=1763&start=10) in the hope that it is simply my not calling the correct variable for initialising the displacement.
Does it also crash without the initialization user subroutine (in which case we can try to reproduce the issue ?).
If it only crashes with that routine, could you post both the routine and the GUI XML file (the combination of the two defining the setup completely, assuming a given mesh)
So it is now working with the GUI only, though of course this does not fully define my case since I need the free surface to be initially displaced which I cannot do through the GUI.
When I include my cs_user_initialisation script to do this it exits with a memory error:
“SIGSEGV signal (forbidden memory area access) intercepted!”
A different error to before…progress?
I have attached the mesh, xml and cs_user_initialization scripts
If you still have issues after this fix, comment lines in your file (for example inside the loop) until you determine exactly which line is related to the crash.
Here is part of my issue. I do not know what the variable is I should be calling! I took the impale, depale stuff from the ALE tutorial, and redefined them as it threw uninitialised errors if I didn’t. I’d never read or heard about albase before. Do I use xstr0, which is an ale variable, in which case I need to have defined a structure for internal coupling right?
Sorry I am very frustrated with this, I know my fortran is crap but I find it very hard to find specific variable information without knowing the name of the variable I am interested in. If you could point me to somewhere, anywhere, that explains what variables I should be using to set an initial mesh displacement without internal/external ale coupling I would be so so grateful.
No, these arrays are not currently defined as fields (they may be in the future), they are direclty defined as arrays in the albase module, so adding “use alebase” is enough.
In any case, when referring to a variable you find in older tutorials or examples, search for that name in the Doxygen documentation of the code. You should find both the matching module/field name, … and description, at least in most cases (for example, impale is described, depale missing)…
Also, if you are not familiar with programming, as a general rule, whatever the programming language, think as if variables were math variables: if you use one without defining it first, things won’t work. When a variable is defined in a module, you can expect that it has been initialized, but if you define it locally, you must define it yourself, and it must serve some local purpose.
I do use the Doxygen pages a lot but I guess in this case I can’t find a variable in an old tutorial so don’t have a starting off point for what I am looking for other than asking on this forum.
Could you confirm that depale, impale and xyzno0 are what I should be using to initialise a free surface displacement in cs_user_initialisation? They are used in usalcl.f90, where they have been defined in the variables section without calling abase. Depale also isn’t included anywhere in albase as far as I can see.
I’m actually not knowledgeable enough in the ALE part of the code to tell you what needs to be computed first, an what works, what doesn’t…
xyzno0 is the “initial position” of vertices. Between depale (displacement) and impale (prescribed positions), I am not sure what is effective in the beginning of the time step and what becomes effective after…
I’ll let Martin or someone who has more experience with ALE answer that one… or you can experiment…
I am still struggling with this. Is Martin currently active on the forum? Or anyone who is knowledgeable about the free surface side of code_saturne? Or should I be enquiring somewhere else?