"Invalid line number" when compiling at runtime

satter_partier · June 29, 2019, 06:50

Hi to all,

I'm currently using the CINECA cluster to perform some heavy simulations,

Due to not better known reasons OpenFoam 5.0 was removed from the cluster and I had to use other versions installed (v17.. v18..).

My post process deeply relies on function objects and runtime calculations, everything was working five on the version 5, but fails in all the others.

The issue, in particular, happens any time a dynamic compilation is required at runtime, i.e. "#calc" in dictionaries or coded FO. The error is named "line error",
here below, part of the log running pimpleFoam on a classic tutorial with the unique modification of a #calc put in the transportDictionary.

Code:

Using #calc at line 22 in file "....../run/channel395/constant/transportProperties"
Using #codeStream with "......./run/channel395/dynamicCode/platforms/linux64IccDPInt32Opt/lib/libcodeStream_cfc4d58601dcd933810013f2a73aa94cc39c84f5.so"
Creating new library in "dynamicCode/_cfc4d58601dcd933810013f2a73aa94cc39c84f5/platforms/linux64IccDPInt32Opt/lib/libcodeStream_cfc4d58601dcd933810013f2a73aa94cc39c84f5.so"
Invoking wmake libso ...../run/channel395/dynamicCode/_cfc4d58601dcd933810013f2a73aa94cc39c84f5
wmake libso ....../run/channel395/dynamicCode/_cfc4d58601dcd933810013f2a73aa94cc39c84f5
    ln: ./lnInclude
    dep: codeStreamTemplate.C
    Ctoo: codeStreamTemplate.C
codeStreamTemplate.C(61): error: invalid line number
          #line 0 ""
                ^

compilation aborted for codeStreamTemplate.C (code 2)
make: *** [Make/linux64IccDPInt32Opt/codeStreamTemplate.o] Error 2


--> FOAM FATAL IO ERROR: 
Failed wmake "dynamicCode/_cfc4d58601dcd933810013f2a73aa94cc39c84f5/platforms/linux64IccDPInt32Opt/lib/libcodeStream_cfc4d58601dcd933810013f2a73aa94cc39c84f5.so"


file: ......./run/channel395/constant/transportProperties

    From function static void (*Foam::functionEntries::codeStream::getFunction(const Foam::dictionary &, const Foam::dictionary &))(Foam::Ostream &, const Foam::dictionary &)
    in file db/dictionary/functionEntries/codeStream/codeStream.C at line 220.

FOAM exiting

The system calls operation are allowed, and on my local machine with the same versions of OpenFOAM everything behaves well.

I'm wondering if any of you may know the cause of such issue. Googling didn't provide much help, and the customer service from the cluster does not respond.

Best,
Gabriele

t.teschner · July 1, 2019, 05:17

switching from version 5.0 to 17/18 sounds like switching from the distribution provided by foundation (https://openfoam.org/) to the one provided by the esi group (https://openfoam.com/) ... function objects (at least according to my memory) used to be the same in both distribution but changed in the past few years in both distributions. the best advice i can offer is probably to check any tutorial on your local machine and check how the same tutorial is done in the other openfoam version (i.e. the one on the cluster). any differences should be visible in the tutorial files. that is, if any of the tutorials cover what you want to achieve ...

satter_partier · July 1, 2019, 05:52

Dear Tom,

thanks for the kind reply.
Sorry to not have been thoroughly clear. But exacty version 5.0 from the fundation and "v--" from the esi group.

Actually, there is no difference on the way function object should be formulated between these version.

Checking the source code, codedFunctionObject.H the reported example is the same.
I was also able to test on my machine with the version v18.12 and the compilation of my CFO gave no problem.
Thus i think the problem is not connected to the function obects, but to some issue in the compiler. Since it fails even when compiling run time calculation.

einstein_zee · July 1, 2019, 09:45

Quote:

Originally Posted by satter_partier

Hi to all,

I'm currently using the CINECA cluster to perform some heavy simulations,

Due to not better known reasons OpenFoam 5.0 was removed from the cluster and I had to use other versions installed (v17.. v18..).

My post process deeply relies on function objects and runtime calculations, everything was working five on the version 5, but fails in all the others.

The issue, in particular, happens any time a dynamic compilation is required at runtime, i.e. "#calc" in dictionaries or coded FO. The error is named "line error",
here below, part of the log running pimpleFoam on a classic tutorial with the unique modification of a #calc put in the transportDictionary.

Code:

Using #calc at line 22 in file "....../run/channel395/constant/transportProperties"
Using #codeStream with "......./run/channel395/dynamicCode/platforms/linux64IccDPInt32Opt/lib/libcodeStream_cfc4d58601dcd933810013f2a73aa94cc39c84f5.so"
Creating new library in "dynamicCode/_cfc4d58601dcd933810013f2a73aa94cc39c84f5/platforms/linux64IccDPInt32Opt/lib/libcodeStream_cfc4d58601dcd933810013f2a73aa94cc39c84f5.so"
Invoking wmake libso ...../run/channel395/dynamicCode/_cfc4d58601dcd933810013f2a73aa94cc39c84f5
wmake libso ....../run/channel395/dynamicCode/_cfc4d58601dcd933810013f2a73aa94cc39c84f5
    ln: ./lnInclude
    dep: codeStreamTemplate.C
    Ctoo: codeStreamTemplate.C
codeStreamTemplate.C(61): error: invalid line number
          #line 0 ""
                ^

compilation aborted for codeStreamTemplate.C (code 2)
make: *** [Make/linux64IccDPInt32Opt/codeStreamTemplate.o] Error 2


--> FOAM FATAL IO ERROR: 
Failed wmake "dynamicCode/_cfc4d58601dcd933810013f2a73aa94cc39c84f5/platforms/linux64IccDPInt32Opt/lib/libcodeStream_cfc4d58601dcd933810013f2a73aa94cc39c84f5.so"


file: ......./run/channel395/constant/transportProperties

    From function static void (*Foam::functionEntries::codeStream::getFunction(const Foam::dictionary &, const Foam::dictionary &))(Foam::Ostream &, const Foam::dictionary &)
    in file db/dictionary/functionEntries/codeStream/codeStream.C at line 220.

FOAM exiting

The system calls operation are allowed, and on my local machine with the same versions of OpenFOAM anything behaves well.

I'm wondering if any of you may know the cause of such issue. Googling didn't provide much help, and the customer service from the cluster does not respond.

Best,
Gabriele

Hey there,

The easiest solution would be to compile OF 5.0 from source code in your cluster. For compiling from source you don't need root permissions...

choch · July 12, 2019, 20:47

Hello Gabriele and all,

I know this thread is pretty new, but I run into the same problem. When trying to compile a "codeDict" boundary condition, an error appears which looks like yours:

HTML Code:

fixedValuePointPatchFieldTemplate.C(32): error: invalid line number
  #line 0 etc

Now, I went back using OpenFOAM/6.0, started the simulation lauching interDyMFoam (so far all went well) and stopped the simulation after a few time steps.

I went back loading OpenFOAM/v1812 and started the simulation directly with interFoam and... it started with no error !

That is obviously not a long term fix but it might be useful when waiting the response from the cluster service.

Cheers,

Charlie

choch · July 12, 2019, 22:12

Hi again,

Actually to make it work you have to manually change .C file in dynamicCode/libraryFolder/fixedValuePointPatchFieldTemplate.C and change "#line 0" by the suitable line number.

Still not a good solution but it can be useful.

olesen · July 16, 2019, 06:48

Quote:

Originally Posted by choch

Hi again,

Actually to make it work you have to manually change .C file in dynamicCode/libraryFolder/fixedValuePointPatchFieldTemplate.C and change "#line 0" by the suitable line number.

Still not a good solution but it can be useful.

This is what you are looking for (was fixed in the 1906 release).
https://develop.openfoam.com/Develop...us/issues/1282

The problem arose from trapping of 'not-found' entries. In OpenFOAM the line numbers start from 0, which are incremented by 1 when generating the pre-processor line directive. The line 0 is spurious output from when an entry is not found. It doesn't bother gcc or clang, but does rather upset the intel compiler.

Solution(s):
- upgrade to 1906
- use the maintenance-v1812 branch
- manually change the two lines within src/OpenFOAM/db/dynamicLibrary/dynamicCode/dynamicCodeContext.C (around line 120-130)

satter_partier · July 16, 2019, 07:01

Thanks to everyone for the kind replies.

Eventually the customer service responded and the issues on the cluster i mentioned seem gone to me. But it's good to know the reason of the problem and a temporary fix.

July 12, 2019, 20:47		#5
choch New Member Charlie Barraud Join Date: Jun 2016 Posts: 5 Rep Power: 10	Hello Gabriele and all, I know this thread is pretty new, but I run into the same problem. When trying to compile a "codeDict" boundary condition, an error appears which looks like yours: HTML Code: fixedValuePointPatchFieldTemplate.C(32): error: invalid line number #line 0 etc Now, I went back using OpenFOAM/6.0, started the simulation lauching interDyMFoam (so far all went well) and stopped the simulation after a few time steps. I went back loading OpenFOAM/v1812 and started the simulation directly with interFoam and... it started with no error ! That is obviously not a long term fix but it might be useful when waiting the response from the cluster service. Cheers, Charlie

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
[Other] refineWallLayer Error	Yuby	OpenFOAM Meshing & Mesh Conversion	2	November 11, 2021 12:04
problem during mpi in server: expected Scalar, found on line 0 the word 'nan'	muth	OpenFOAM Running, Solving & CFD	3	August 27, 2018 05:18
[OpenFOAM] Annoying issue of automatic "Rescale to Data Range " with paraFoam/paraview 3.12	keepfit	ParaView	60	September 18, 2013 04:23
Problems of Duns Codes!	Martin J	Main CFD Forum	8	August 15, 2003 00:19
error while compiling the USER Sub routine	CFD user	CFX	3	November 25, 2002 16:16

July 1, 2019, 05:17		#2
t.teschner Senior Member Tom-Robin Teschner Join Date: Dec 2011 Location: Cranfield, UK Posts: 211 Rep Power: 17	switching from version 5.0 to 17/18 sounds like switching from the distribution provided by foundation (https://openfoam.org/) to the one provided by the esi group (https://openfoam.com/) ... function objects (at least according to my memory) used to be the same in both distribution but changed in the past few years in both distributions. the best advice i can offer is probably to check any tutorial on your local machine and check how the same tutorial is done in the other openfoam version (i.e. the one on the cluster). any differences should be visible in the tutorial files. that is, if any of the tutorials cover what you want to achieve ...

July 1, 2019, 05:52		#3
satter_partier New Member gabriele centurelli Join Date: Nov 2018 Posts: 3 Rep Power: 8	Dear Tom, thanks for the kind reply. Sorry to not have been thoroughly clear. But exacty version 5.0 from the fundation and "v--" from the esi group. Actually, there is no difference on the way function object should be formulated between these version. Checking the source code, codedFunctionObject.H the reported example is the same. I was also able to test on my machine with the version v18.12 and the compilation of my CFO gave no problem. Thus i think the problem is not connected to the function obects, but to some issue in the compiler. Since it fails even when compiling run time calculation.

July 12, 2019, 22:12		#6
choch New Member Charlie Barraud Join Date: Jun 2016 Posts: 5 Rep Power: 10	Hi again, Actually to make it work you have to manually change .C file in dynamicCode/libraryFolder/fixedValuePointPatchFieldTemplate.C and change "#line 0" by the suitable line number. Still not a good solution but it can be useful.

July 16, 2019, 07:01		#8
satter_partier New Member gabriele centurelli Join Date: Nov 2018 Posts: 3 Rep Power: 8	Thanks to everyone for the kind replies. Eventually the customer service responded and the issues on the cluster i mentioned seem gone to me. But it's good to know the reason of the problem and a temporary fix.