View Issue Details

IDProjectCategoryView StatusLast Update
0002386OpenFOAM[All Projects] Bugpublic2016-12-19 11:16
ReporterzbliAssigned Towyldckat 
Status closedResolutionno change required 
PlatformGNU/LinuxOSTumbleweedOS Version20161203
Product Version 
Fixed in Version 
Summary0002386: Cannot compile the code with error " ‘psiuReactionThermo’ was not declared in this scope"
DescriptionThe compiler is gcc-6.2.1 and I also tried with gcc-4.9.4.
I just followed the installation instruction for opensuse on the Wiki
Prerequisites are all set.
These are the lines of stderr where it begins:

In file included from /home/jason/OpenFOAM/OpenFOAM-4.1/src/OpenFOAM/lnInclude/postProcess.H:129:0,
                 from coldEngineFoam.C:47:
../XiFoam/createFields.H: In function ‘int main(int, char**)’:
../XiFoam/createFields.H:3:9: error: ‘psiuReactionThermo’ was not declared in this scope
 autoPtr<psiuReactionThermo> pThermo
../XiFoam/createFields.H:3:27: error: template argument 1 is invalid
 autoPtr<psiuReactionThermo> pThermo
../XiFoam/createFields.H:5:5: error: ‘psiuReactionThermo’ is not a class, namespace, or enumeration
../XiFoam/createFields.H:7:21: error: ‘thermo’ was not declared in this scope
 psiuReactionThermo& thermo = pThermo();
../XiFoam/createFields.H:7:38: error: ‘pThermo’ cannot be used as a function
 psiuReactionThermo& thermo = pThermo();
../XiFoam/createFields.H:10:1: error: ‘basicMultiComponentMixture’ was not declared in this scope
 basicMultiComponentMixture& composition = thermo.composition();
../XiFoam/createFields.H:10:29: error: ‘composition’ was not declared in this scope
 basicMultiComponentMixture& composition = thermo.composition();
In file included from /home/jason/OpenFOAM/OpenFOAM-4.1/src/OpenFOAM/lnInclude/postProcess.H:129:0,
                 from coldEngineFoam.C:47:
../XiFoam/createFields.H:93:9: error: ‘laminarFlameSpeed’ was not declared in this scope
 autoPtr<laminarFlameSpeed> unstrainedLaminarFlameSpeed
../XiFoam/createFields.H:93:26: error: template argument 1 is invalid
 autoPtr<laminarFlameSpeed> unstrainedLaminarFlameSpeed
../XiFoam/createFields.H:95:5: error: ‘laminarFlameSpeed’ is not a class, namespace, or enumeration
../XiFoam/createFields.H:93:28: warning: unused variable ‘unstrainedLaminarFlameSpeed’ [-Wunused-variable]
 autoPtr<laminarFlameSpeed> unstrainedLaminarFlameSpeed
make[2]: *** [/home/jason/OpenFOAM/OpenFOAM-4.1/wmake/rules/General/transform:8: /home/jason/OpenFOAM/OpenFOAM-4.1/platforms/linux64GccDPInt32Opt/applications/solvers/combustion/coldEngineFoam/coldEngineFoam.o] Error 1
make[1]: *** [/home/jason/OpenFOAM/OpenFOAM-4.1/wmake/makefiles/apps:39: coldEngineFoam] Error 2
make: *** [/home/jason/OpenFOAM/OpenFOAM-4.1/wmake/makefiles/apps:39: combustion] Error 2
make: *** Waiting for unfinished jobs....
Making dependency list for source file rhoPimpleDyMFoam.C
Making dependency list for source file mdFoam.C
Making dependency list for source file rhoPorousSimpleFoam.C
+ wmake
Making dependency list for source file rhoCentralFoam.C
In file included from /home/jason/OpenFOAM/OpenFOAM-4.1/src/OpenFOAM/lnInclude/postProcess.H:129:0,
                 from rhoPorousSimpleFoam.C:44:
../createFields.H: In function ‘int main(int, char**)’:
../createFields.H:3:9: error: ‘psiThermo’ was not declared in this scope
 autoPtr<psiThermo> pThermo
../createFields.H:3:18: error: template argument 1 is invalid
 autoPtr<psiThermo> pThermo
../createFields.H:5:5: error: ‘psiThermo’ is not a class, namespace, or enumeration
../createFields.H:7:12: error: ‘thermo’ was not declared in this scope
 psiThermo& thermo = pThermo();
../createFields.H:7:29: error: ‘pThermo’ cannot be used as a function
 psiThermo& thermo = pThermo();
make[3]: *** [/home/jason/OpenFOAM/OpenFOAM-4.1/wmake/rules/General/transform:8: /home/jason/OpenFOAM/OpenFOAM-4.1/platforms/linux64GccDPInt32Opt/applications/solvers/compressible/rhoSimpleFoam/rhoPorousSimpleFoam/rhoPorousSimpleFoam.o] Error 1
make[2]: *** [/home/jason/OpenFOAM/OpenFOAM-4.1/wmake/makefiles/apps:39: rhoPorousSimpleFoam] Error 2
make[1]: *** [/home/jason/OpenFOAM/OpenFOAM-4.1/wmake/makefiles/apps:39: rhoSimpleFoam] Error 2
make[1]: *** Waiting for unfinished jobs....
Making dependency list for source file scalarTransportFoam.C
Making dependency list for source file rhoPimpleFoam.C
+ wmake rhoCentralDyMFoam
Making dependency list for source file rhoCentralDyMFoam.C
make: *** [/home/jason/OpenFOAM/OpenFOAM-4.1/wmake/makefiles/apps:39: compressible] Error 2
TagsNo tags attached.



2016-12-12 13:13

updater   ~0007460

Any chance you could attach the full log file? Please run it like this:

  ./Allwmake > log.make 2>&1
  gzip < log.make > log.make.gz

Then attach the file "log.make.gz".

I ask this because it looks very strange that the build would only start to fail when building the solvers.


2016-12-13 03:28


make.log.gz (81,076 bytes)


2016-12-13 03:29

reporter   ~0007465

Sure, I have uploaded the log file.
Please check it out.


2016-12-13 21:13

updater   ~0007468

OK, so the good news is that the error message that you've provided had all of the necessary information for diagnosing the problem. Nonetheless, having the log file reduced the number of possible reasons as to what happened.

The not so good news is that this error is still a bit strange. The problem seems to be that the file "createFields.H" is missing from the directory "applications/solvers/combustion/coldEngineFoam", which is why the compiler picked up instead the file at "applications/solvers/combustion/XiFoam".

Therefore, can you please confirm if the file "applications/solvers/combustion/coldEngineFoam/createFields.H" exists in your installation?
You can double-check by running (with the OpenFOAM 4.1 environment activated):

  ls -l $FOAM_SOLVERS/combustion/coldEngineFoam/createFields.H

For example, for me it gave this:

  -rw-rw-r-- 1 ofuser ofuser 1185 Out 16 15:11 /home/ofuser/OpenFOAM/OpenFOAM-4.1/applications/solvers/combustion/coldEngineFoam/createFields.H


2016-12-14 03:58

reporter   ~0007469

Thanks for your note. However, it's right there, createFields.H


2016-12-15 00:08

updater   ~0007482

I should have asked you to also provide the output of the 'ls' command that I wrote above. If you can, please post what the command I wrote int he previous comment gives you.

Because something very strange is going on in the file-system on your machine, given that I've finished testing just now with a clean installation on openSUSE Tumbleweed (20161213) and it built OpenFOAM 4.1 without issues, specially no problems with "coldEngineFoam".

Let's try and continue the build, regardless of the problem with "coldEngineFoam". To do this, run "Allwmake" like this:

  ./Allwmake -k -j 4 > log.make2 2>&1
  gzip < log.make2 > log.make2.gz

Then please attach the file "log.make2.gz". The "-k" option will continue the build regardless of any errors, while the "-j 4" is for using 4 cores to finish build faster.


2016-12-15 00:36

updater   ~0007483

By the way, I'm able to reproduce the same exact error if the "createFields.H" file is actually a dead symbolic link:

  lrwxrwxrwx 1 ofuser users 6 Dec 15 00:31 createFields.H -> cookie

"cookie" is a dummy name I've used that doesn't exist as a file nor folder.


2016-12-15 01:23

reporter   ~0007484

My release is 20161203.
Sure thing. I'll give it a try and attach all the files.


2016-12-15 02:59

reporter   ~0007485

$ ls -l createFields.H
-rw-r--r-- 1 jason users 1185 Oct 16 22:11 createFields.H
My colleague suggested me to drop off the line of '../XiFoam' in the options file and the compilation worked, yet another issue came up when I tried to make a similar change to reactingFoam. At the beginning I wonder maybe it is caused by the searching order of the system when the compiler attempts to include header files. I made a small test and it seemed alright with that.

The good thing is using -k option I got nearly all stuff set up except the error compiled ones. Quite confusing though.

I've got the log file attached. Please check it out.
Thank you again.


2016-12-15 03:00


make2.log.gz (142,540 bytes)


2016-12-16 00:19

updater   ~0007493

I didn't check all of the solvers that failed to be built in your machine, but a fair number of the solvers that didn't build properly, all seemed to be relying on the "-I." include path.

This is part of a technique that is used in OpenFOAM to not include duplicate header files which solvers use.

Now, whatever is going on wrong in your installation, may or may not be related to using openSUSE Tumbleweed. It feels like the problem has to do with some specific personalization that you've done in your installation, such as the following possibilities:

 1. Is either the path "/home/jason/OpenFOAM" or "/home/jason/OpenFOAM/OpenFOAM-4.1" a symbolic path to another location where the source code is actually located?

 2. Do you use any special/customized shell functions? For example, does the command "type cd" give you the following output?

      $ type cd
      cd is a shell builtin

    Or does it give you something else?

 3. Do you know if you have any special environment variables set? For example, "CPLUS_INCLUDE_PATH"?
    If possible, please run the following commands:

      export > log.export
      gzip < log.export > log.export.gz

    and attach the file "log.export.gz" here, so that we can double-check if there is any suspicious environment variable that is interfering with the standard installation environment that OpenFOAM expects.

There are probably several other possibilities, but these are only the ones I can think of at the moment.


2016-12-16 02:56

reporter   ~0007494

1. I haven't done anything to link the source code directory, so the OpenFOAM is located where it should be.
2. The "type cd" command shows the same one
cd is a shell builtin
3. I did customize some environment variables, so please check the log file attached.

Thanks for your time.

export.log.gz (2,885 bytes)


2016-12-18 23:44

updater   ~0007514

I've finally managed to take a look at the "log.export" file.
I have four suspect environment variables that I would like to ask you to unset:


The first two could potentially affect the OpenFOAM builds, but I'm not 100% that it would affect in this case. The other two seem too suspicious to me.

Therefore, please try the following steps:

  1. Start a new terminal window and activate the OpenFOAM shell environment (the source command), if it's not done automatically.

  2. Unset those 4 variables, by running:


  3. Then try building one of the solvers that have issues. For example "coldEngineFoam", so please make sure you have the original "Make/options" file and then run:

    cd $FOAM_SOLVERS/combustion/coldEngineFoam

With luck, this solves the problem.


2016-12-19 00:05

updater   ~0007515

I was really curious about this and tested it myself. It's the 'CPLUS_INCLUDE_PATH' that is broken. You have this:


The colon ':' at the end leaves the search path broken and ignores '-I.' as a consequence of that. This is possibly because the compiler unrolls the options as:

  -I/home/jason/installed/hdf5/include -I/home/jason/installed/hdf5/include -I -I.

Problem is that the empty entry '-I' leads to a parsing error that instead of reporting it as an error, it assumes the path is something like ' -I.'

There are two possible solutions:

  1. Either clean up the way you set that variable, to something like this:


  2. Or unset it completely from the default environment paths.

Side note to @Mattijs: Remember what I wrote about relying on 'CPATH' in #2330? This is one of the reasons why it is somewhat dangerous to do it, at least if always set. Although this bug doesn't happen with 'CPATH', it seems to only happens with 'CPLUS_INCLUDE_PATH'...


2016-12-19 00:08

updater   ~0007516

(Sorry, meant to tag @MattijsJ regarding the previous comment.)


2016-12-19 00:30

updater   ~0007517

FYI I tried to reproduce the error with a simple test case, in order to report it at GCC's bugzilla, but due to whatever reason, I'm only to reproduce this error with OpenFOAM's wmake stack...


2016-12-19 02:17

reporter   ~0007519

Thanks bro.
I guess your suspicion is right. It finally works.
I'll look into my environment more carefully.


2016-12-19 11:16

updater   ~0007521

OK, good thing we've finally managed to narrow it down. I'm closing this bug report as "no change required", because this is related to other rare issues that occur when people have questionable environment options (see issue #2311 ).

I'll try to isolate this issue at a later time, since this feels like it's a very weird bug in GCC.

Issue History

Date Modified Username Field Change
2016-12-12 06:47 zbli New Issue
2016-12-12 13:13 wyldckat Note Added: 0007460
2016-12-13 03:28 zbli File Added: make.log.gz
2016-12-13 03:29 zbli Note Added: 0007465
2016-12-13 21:13 wyldckat Note Added: 0007468
2016-12-14 03:58 zbli Note Added: 0007469
2016-12-15 00:08 wyldckat Note Added: 0007482
2016-12-15 00:36 wyldckat Note Added: 0007483
2016-12-15 01:23 zbli Note Added: 0007484
2016-12-15 02:59 zbli Note Added: 0007485
2016-12-15 03:00 zbli File Added: make2.log.gz
2016-12-16 00:19 wyldckat Note Added: 0007493
2016-12-16 02:56 zbli File Added: export.log.gz
2016-12-16 02:56 zbli Note Added: 0007494
2016-12-18 23:44 wyldckat Note Added: 0007514
2016-12-19 00:05 wyldckat Note Added: 0007515
2016-12-19 00:08 wyldckat Note Added: 0007516
2016-12-19 00:30 wyldckat Note Added: 0007517
2016-12-19 02:17 zbli Note Added: 0007519
2016-12-19 11:16 wyldckat Assigned To => wyldckat
2016-12-19 11:16 wyldckat Status new => closed
2016-12-19 11:16 wyldckat Resolution open => no change required
2016-12-19 11:16 wyldckat Note Added: 0007521