[sita]

Hi all,

Up to this morning I had a working install of OpenFOAM-dev on our Scientific Linux 7 cluster. After pulling the latest update and building it (following the instructions here: git pull, ./Allwmake -j -update > log.make 2>&1), the whole thing stopped working: any OF-dev command now returns "segmentation fault (core dumped)".

As I couldn't find any obvious errors in my log.make, and "wcleanPlatform" didn't help either, in the end I decided to zip my OpenFOAM-dev folder, re-clone the repository into a new OpenFOAM-dev folder, and re-build it (leaving the ThirdParty-dev folder untouched). Again, ./Allwmake seemed to run alright, but still, nothing in OpenFOAM-dev works.

Does anyone have any ideas on how I could repair my OpenFOAM-dev install? Should I also re-clone and re-build the ThirdParty bit? Or try a different version altogether?

Many thanks!
Sita

[sita]

Update: in the meantime I successfully installed OpenFOAM-7, then found out that the bug that made me want to update in the first place was still there. So I proceeded to install OpenFOAM-dev from scratch (according to the bug report, this bug was fixed in OpenFOAM-dev on 6 June, but apparently the fix didn't make it into OpenFOAM-7).

For both installs I used these instructions: https://openfoamwiki.net/index.php/I...CentOS_SL_RHEL, which didn't produce any errors, as far as I can see now.

Unfortunately, commands in OpenFOAM-dev still give me "Segmentation fault (core dumped)". I'm attaching my log.make (as a zip-file), can anyone see anything out of the ordinary here?

Thanks!
Sita

[sita]

Hi all,

A few days ago I installed OpenFOAM-7, following these instructions: https://openfoamwiki.net/index.php/I...CentOS_SL_RHEL

Everything works smoothly now, but whenever I use the source alias that's suggested in the above instructions,

source /opt/OpenFOAM/OpenFOAM-7/etc/bashrc WM_COMPILER_TYPE=ThirdParty WM_COMPILER=Gcc48 WM_MPLIB=OPENMPI FOAMY_HEX_MESH=yes

other programs, like gedit, no longer work. Instead, I get "ImportError: No module named site".

Just sourcing /opt/OpenFOAM/OpenFOAM-7/etc/bashrc doesn't cause this issue, but then paraFoam won't work (FATAL ERROR: The official reader module for OpenFOAM data does not exist on your system, etc.).

For now I've worked around this issue by using two separate aliases, one for just using OF7, and one for when I want to use paraFoam, but this is a bit cumbersome. Also, I feel a bit silly, using an alias of which I'm not completely sure what it does... After playing around with the options in the long alias, it seems that it's the WM_COMPILER=Gcc48 that makes the difference, but I wouldn't know why this is the case.

So, does anyone know how to get both paraFoam and gedit/other programs working at the same time? My brute-force solution would be to reinstall OpenFOAM-7, using our system GCC (turns out we do have 4.8.5, but I only realised that halfway through the installation), but I'd prefer an easier solution of course...

Many thanks,
Sita

[wyldckat]

Quick question: On the page https://openfoamwiki.net/index.php/I...CentOS_SL_RHEL there are instructions for CentOS 6 and CentOS 7. Which specific instructions did you follow?

Because if you followed the instructions that were designed for CentOS 6 but on SL 7, then that's why you are having those problems.

[sita]

Thanks for getting back. I'm afraid I mostly used the CentOS 6 (without SCL) instructions, as these included the installation of Qt (I remembered having trouble with our system Qt when I installed our previous OpenFOAM version). Probably I should have paid attention and not have installed the components I didn't need, but in my frustration about not being able to simply update or even reinstall OpenFOAM-dev, I may not have been too focused...

What do you think, would it be best for me to take a deep breath and just do a clean install using the proper instructions? Or is there a simpler work-around?

[wyldckat]

Hi Sita,

So the first detail I hadn't noticed before is that you installed at "/opt"... which is potentially dangerous, mostly if you compiled OpenFOAM as root, which could risk you to damage your Scientific Linux (SL) installation entirely, if a file had ended up on the wrong place...

But so far, there is no indication of that having happened, given the current problem is that there is conflict between SL's GCC 4.8.5 and the custom build of GCC 4.8.5 that was built for OpenFOAM, but that conflict only occurs when you activate OpenFOAM's shell environment.

My suggestion is that you currently don't touch your existing installation, so that you can run cases in the meantime. But once you've gotten a bit more time and patience, build OpenFOAM into your home folder as a normal user, by following the installation instructions intended for CentOS/SL 7, given that you can activate each version/location manually and independently.

As for fixing the problem with using your system's Qt version, you can choose to only use the Qt 5 related commands/steps from the "without SCL" instructions that were written for CentOS 6. Hopefully this will get you a working installation of ParaView+Qt 5, without making any damages.

Once things are completed... I know I wrote about this in the past, but the problem is finding where I wrote it... but the idea is that you can copy your installation from your home folder to your "/opt" folder and there shouldn't be much of a problem with paths, as long as you change the file system permissions to match the conventional ones for "/opt".

Best regards,
Bruno

[sita]

Hi Bruno,

Thanks for the extensive explanation! That's good to know, about installing under /opt, I'll let our system administrator know as well. I'll try as you suggested, installing in my /home folder and moving everything to /opt later on, see how that goes.

Sita

[sita]

Great, it worked! Thanks again for your help!

[sita]

Noooo!! I was too optimistic: running jobs in parallel doesn't work now. This is the error I get:

It looks like opal_init failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during opal_init; some of which are due to configuration or
environment problems.  This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):

  opal_shmem_base_select failed
  --> Returned value -1 instead of OPAL_SUCCESS

Any ideas, anyone?

Thanks!
Sita


P.S. I've been looking around on this forum, and apparently I'm not the only one with this problem. The thing is that the solutions I came across are rather old already, so I don't really dare trying them yet...

[sita]

Solved for now! What worked for me in the end was to use

export OPAL_LIBDIR=$OPAL_PREFIX/lib64/

as suggested here.

I've added this line to .../OpenFOAM-7/etc/config.sh/mpi, but I'm not quite sure whether that's the proper way to fix this. I mean, it does fix my problem, but it feels a bit drastic somehow, to edit that file, and I'm afraid it may get me into trouble when I need to update. Should I have added this bit to my of7 alias instead?