[Jonathan]

Hi everyone,

i wonder if one (or two ) of the Extend project guys could give me a hand with an installation problem i am having!

I am trying to install the nextRelease branch of OF-1.6-ext, and the install is hanging when it tries to download the RPM packages for:

Package name      : ParMGridGen-1.0
Package URL       : ftp://ftp.proxad.net/.mirrors1/ftp.freebsd.org/ports/distfiles/ParMGridGen-1.0.tar.gz
RPM spec file name: ParMGridGen-1.0.spec
Additional flags  : 
Updating the ThirdParty environment variables before building package ParMGridGen-1.0
RPM file name     : /home/jonathan/OpenFOAM/OpenFOAM-1.6-ext_nextRelease/ThirdParty/rpmBuild/RPMS/x86_64/ParMGridGen-1.0-linux64Gcc46DPOpt.x86_64.rpm
Download ParMGridGen-1.0.tar.gz from : ftp://ftp.proxad.net/.mirrors1/ftp.freebsd.org/ports/distfiles/ParMGridGen-1.0.tar.gz
--2013-10-08 11:55:17--  ftp://ftp.proxad.net/.mirrors1/ftp.freebsd.org/ports/distfiles/ParMGridGen-1.0.tar.gz
           => `ParMGridGen-1.0.tar.gz'
Resolving localhost (localhost)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:3128... connected.
Logging in as anonymous ... 
Error in server response, closing control connection.
Retrying.

When i install the standard release, this package is downloaded perfectly and the install runs fine - the issue is, the package comes from a different source, and i don't know where in the make files / rules to change the repo address!!

Package name      : ParMGridGen-1.0
Package URL       : http://www.mgnet.org/mgnet/Codes/parmgridgen/ParMGridGen-1.0.tar.gz
RPM spec file name: ParMGridGen-1.0.spec
Additional flags  : 
Updating the ThirdParty environment variables before building package ParMGridGen-1.0
Download ParMGridGen-1.0.tar.gz from : http://www.mgnet.org/mgnet/Codes/parmgridgen/ParMGridGen-1.0.tar.gz
--2013-10-07 16:43:53--  http://www.mgnet.org/mgnet/Codes/parmgridgen/ParMGridGen-1.0.tar.gz
Resolving localhost (localhost)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:3128... connected.
Proxy request sent, awaiting response... 200 OK
Length: 2623528 (2.5M) [application/x-gzip]
Saving to: `ParMGridGen-1.0.tar.gz'

As you can see the repo for this package is different in the main branch ...

Does anyone know where i can make the change to point to the working repo? As far as i can see from the package name, the package is identical, so changing it should not be a problem.

Many thanks and best regards
Jonathan

[Jonathan]

Hi,

ok, so if anyone else is wondering - i think i have solved this -

you can change the repository address in:

AllMake.stage3

# ParMGridGen
if [ -z "$PARMGRIDGEN_SYSTEM" ]
then
    ( rpm_make -p ParMGridGen-1.0 -s ParMGridGen-1.0.spec -u http://www.mgnet.org/mgnet/Codes/parmgridgen/ParMGridGen-1.0.tar.gz       )
    #( rpm_make -p ParMGridGen-1.0 -s ParMGridGen-1.0.spec -u ftp://ftp.proxad.net/.mirrors1/ftp.freebsd.org/ports/distfiles/ParMGridGen-1.0.tar.gz       )
else
    echo "Using system installed ParMGridGen"
    echo ""
fi

I don't know if changing this repo will break the installation, but ThirdParty compiled OK.

i am yet to test the install to see that everything works, but it appears it will.

cheers
jonathan

[hjasak]

Interesting: it seems that some mirrors are available in some parts of the world and others are not.

I have tried:

wget ftp://ftp.proxad.net/.mirrors1/ftp.f...Gen-1.0.tar.gz
wget http://www.mgnet.org/mgnet/Codes/par...Gen-1.0.tar.gz

and both work for me.

Can you please check them by hand and let me know,

Hrv

[Jonathan]

Hi Hrv,

thanks for your reply. I tested by hand and:

jonathan@01:/media/data/temp1-meshing/ICEM/mesh_4/openFoam/tmp$ wget http://www.mgnet.org/mgnet/Codes/parmgridgen/ParMGridGen-1.0.tar.gz
--2013-10-09 12:49:43--  http://www.mgnet.org/mgnet/Codes/parmgridgen/ParMGridGen-1.0.tar.gz
Resolving localhost (localhost)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:3128... connected.
Proxy request sent, awaiting response... 200 OK
Length: 2623528 (2.5M) [application/x-gzip]
Saving to: `ParMGridGen-1.0.tar.gz'

etc

and

jonathan@01:/media/data/temp1-meshing/ICEM/mesh_4/openFoam/tmp$ wget ftp://ftp.proxad.net/.mirrors1/ftp.freebsd.org/ports/distfiles/ParMGridGen-1.0.tar.gz
--2013-10-09 12:48:16--  ftp://ftp.proxad.net/.mirrors1/ftp.freebsd.org/ports/distfiles/ParMGridGen-1.0.tar.gz
           => `ParMGridGen-1.0.tar.gz'
Resolving localhost (localhost)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:3128... connected.
Logging in as anonymous ... 

and hangs ...

(Tested on x2 different machines)

PS I am trying to compile and install the entire nextRelease branch of the Extend project (because i would like to do some turbomachinery calculations), and I have come across a couple things i needed to do to get it to install correctly (actually, i am still working on it, 80% -> finished), so perhaps i could report some of them here (if they actually turn out to be real issues).

many thanks and best regards
jonathan

[Jonathan]

Hi guys,

I am also having some trouble getting swak4foam (AllMake.stage5) to compile on my machine.

I have tried this by running ./AllMake.stage5 from the ThirdParty directory, but also directly by running ./Allwmake and wmake libso in /ThirdParty/rpmBuild/BUILD/swak4Foam-0.2.4/ and /ThirdParty/rpmBuild/BUILD/swak4Foam-0.2.4/Libraries/groovyBC/ respectively, and i am getting the following!

groovyBCJumpFvPatchFields.C:49:5: error: specializing member ‘Foam::groovyBCJumpFvPatchField<double>::typeName’ requires ‘template<>’ syntax
groovyBCJumpFvPatchFields.C:49:5: error: specializing member ‘Foam::groovyBCJumpFvPatchField<double>::debug’ requires ‘template<>’ syntax
make: *** [Make/linux64Gcc46DPOpt/groovyBCJumpFvPatchFields.o] Error 1

which also leads to the later error:

/usr/bin/ld: cannot find -lgroovyBC
collect2: ld returned 1 exit status
make: *** [/home/jonathan/OpenFOAM/site/1.6-ext_nextRelease/lib/linux64Gcc46DPOpt/libgroovyStandardBCs.so] Error 1

and so libgroovyBC.so is not built

I was just wondering if this version of swak had been tested with the nextRelease branch, and whether there was anything i could do to fix it.

again, many thanks and best regards
Jonathan

PS i dont know if i am using the correct forum for these discussions - i didnt know whether there was a particular mailing list where you are supposed to report / discuss this stuff, as up to now i have only been using the releases from OpenCFD. Please correct me if i need to redirect this stuff

System details:

No 'swakConfiguration'. Python etc won't work
Checking swak4Foam-version and generating file
Swak version is 0.2.4
Bison is version 2.5
Flex is version 2.5.35 (Minor version: 35)
OpenFOAM-version: Major 1 Minor 6 Patch 1.6-ext_nextRelease
No swak4FoamParsers/foamVersion4swak.H. Generated

[mbeaudoin]

> PS i dont know if i am using the correct forum for these discussions - i didnt know whether there was a particular mailing list where you are supposed to report / discuss this stuff, as up to now i have only been using the releases from OpenCFD. Please correct me if i need to redirect this stuff

The proper place to report these kind of errors for OpenFOAM-1.6-ext is here:
http://sourceforge.net/apps/mantisbt..._view_page.php

Martin

[gschaider]

Originally Posted by Jonathan

Hi guys,

I am also having some trouble getting swak4foam (AllMake.stage5) to compile on my machine.

I have tried this by running ./AllMake.stage5 from the ThirdParty directory, but also directly by running ./Allwmake and wmake libso in /ThirdParty/rpmBuild/BUILD/swak4Foam-0.2.4/ and /ThirdParty/rpmBuild/BUILD/swak4Foam-0.2.4/Libraries/groovyBC/ respectively, and i am getting the following!

groovyBCJumpFvPatchFields.C:49:5: error: specializing member ‘Foam::groovyBCJumpFvPatchField<double>::typeName’ requires ‘template<>’ syntax
groovyBCJumpFvPatchFields.C:49:5: error: specializing member ‘Foam::groovyBCJumpFvPatchField<double>::debug’ requires ‘template<>’ syntax
make: *** [Make/linux64Gcc46DPOpt/groovyBCJumpFvPatchFields.o] Error 1

which also leads to the later error:

/usr/bin/ld: cannot find -lgroovyBC
collect2: ld returned 1 exit status
make: *** [/home/jonathan/OpenFOAM/site/1.6-ext_nextRelease/lib/linux64Gcc46DPOpt/libgroovyStandardBCs.so] Error 1

and so libgroovyBC.so is not built

I was just wondering if this version of swak had been tested with the nextRelease branch, and whether there was anything i could do to fix it.

It has been. Although I pulled it a month ago. The problem has been brought to my attention but I couldn't reproduce it on my machine

[Jonathan]

thanks Martin,

best regards
jonathan

Originally Posted by mbeaudoin

> PS i dont know if i am using the correct forum for these discussions - i didnt know whether there was a particular mailing list where you are supposed to report / discuss this stuff, as up to now i have only been using the releases from OpenCFD. Please correct me if i need to redirect this stuff

The proper place to report these kind of errors for OpenFOAM-1.6-ext is here:
http://sourceforge.net/apps/mantisbt..._view_page.php

Martin

[Jonathan]

Dear Bernhard

thanks for your reply - any ideas how I can fix it?

I think my setup is fairly benign:

i.e. 
Ubuntu 12.04
GCC 4.6.3
Bison 2.5
Flex 2.5.35

I haven't modified any code apart from downloading the nextRelease branch and compiling it with the above. I did have to change the -ftemplate-depth flag for GCC to 80 (from 40) in order to get the main OF library to compile. I have a working install of swak for OF-2.1.1 which has been a huge help in my work (thanks ).

I am at the moment trying to move everything i am doing onto OF-1.6-ext so I can run some tests with the mixing plane interface.

sincerely and best regards
jonathan

PS I am not saying it is in fact a bona fide bug - i may just have done something incorrectly, but i can't see what!

Originally Posted by gschaider

It has been. Although I pulled it a month ago. The problem has been brought to my attention but I couldn't reproduce it on my machine

[Jonathan]

Hi Bernhard,

I think I found a solution.

In groovyBCJumpFvPatchFields.C, if i change:

namespace Foam
{

// * * * * * * * * * * * * * * Static Data Members * * * * * * * * * * * * * //

    makePatchTypeField(fvPatchScalarField, groovyBCJumpFvPatchScalarField);

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

} // End namespace Foam

// ************************************************************************* //

to

namespace Foam
{

// * * * * * * * * * * * * * * Static Data Members * * * * * * * * * * * * * //

    makeTemplatePatchTypeField(fvPatchScalarField, groovyBCJumpFvPatchScalarField);

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

} // End namespace Foam

// ************************************************************************* //

everything seems to compile Ok?

[gschaider]

Originally Posted by Jonathan

Hi Bernhard,

I think I found a solution.

In groovyBCJumpFvPatchFields.C, if i change:

namespace Foam
{

// * * * * * * * * * * * * * * Static Data Members * * * * * * * * * * * * * //

    makePatchTypeField(fvPatchScalarField, groovyBCJumpFvPatchScalarField);

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

} // End namespace Foam

// ************************************************************************* //

to

namespace Foam
{

// * * * * * * * * * * * * * * Static Data Members * * * * * * * * * * * * * //

    makeTemplatePatchTypeField(fvPatchScalarField, groovyBCJumpFvPatchScalarField);

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

} // End namespace Foam

// ************************************************************************* //

everything seems to compile Ok?

Found that too. Thanks.

My problem with that fix is that is breaks compilation on old 1.6-ext versions (so I'll have to find a way to differentiate between them)

[Jonathan]

Hi Bernhard,

Thanks for the reply ... swak is so good for foam that i can't live without a working install of it! thanks again for contributing it

I just wanted to ask whether there was any particular previous version which was known to definitely work with 1.6-ext?

I have moved my simulations from 2.1.1 / swak for 2.1.1 onto 1.6-ext / swak that comes with the nextRelease branch (0.2.4), and i am struggling (even having gotten it to compile as per above), to get my simulations to run.

Time = 1

[1] swak4Foam: Allocating new repository for sampledGlobalVariables
[3] swak4Foam: Allocating new repository for sampledGlobalVariables
[0] swak4Foam: Allocating new repository for sampledGlobalVariables
[2] swak4Foam: Allocating new repository for sampledGlobalVariables
DILUPBiCG:  Solving for Urelx, Initial residual = 0.0544779267115, Final residual = 0.000849955324891, No Iterations 1
DILUPBiCG:  Solving for Urely, Initial residual = 0.0185173067949, Final residual = 0.000154956162127, No Iterations 1
DILUPBiCG:  Solving for Urelz, Initial residual = 0.0156236887839, Final residual = 0.0001311641489, No Iterations 1
GAMG:  Solving for p, Initial residual = 0.936372869807, Final residual = 0.00751389308468, No Iterations 20
time step continuity errors : sum local = 2.99327913032, global = -0.625890992833, cumulative = -0.625890992833
[bergh01:3619] *** An error occurred in MPI_Recv
[bergh01:3619] *** on communicator MPI_COMM_WORLD
[bergh01:3619] *** MPI_ERR_TRUNCATE: message truncated
[bergh01:3619] *** MPI_ERRORS_ARE_FATAL (your MPI job will now abort)
Inconsistency detected by ld.so: dl-close.c: 759: _dl_close: Assertion `map->l_init_called' failed!
Inconsistency detected by ld.so: dl-close.c: 759: _dl_close: Assertion `map->l_init_called' failed!
Inconsistency detected by ld.so: dl-close.c: 759: _dl_close: Assertion `map->l_init_called' failed!
Inconsistency detected by ld.so: dl-close.c: 759: _dl_close: Assertion `map->l_init_called' failed!

i just want to confirm whether there is something i am doing wrong since i've changed versions (from 2.1.1 to 1.6-ext) and whether you "know" whether it should work with the nextRelease branch!

apologies for the long, somewhat garbled message! its been a long day!

best regards and many thanks
Jonathan

[gschaider]

Originally Posted by Jonathan

Hi Bernhard,

Thanks for the reply ... swak is so good for foam that i can't live without a working install of it! thanks again for contributing it

<blush>

Originally Posted by Jonathan

I just wanted to ask whether there was any particular previous version which was known to definitely work with 1.6-ext?

The problem that you experienced is because 1.6-ext-nextRelease is a moving target. Last month the development version (an the last release) of swak compiled fine with it.

Last release of swak compiled with last release of 1.6-ext. That is all I can say. Next release of swak will compile with whatever is released at that time.

So in general I'd say "Only use released versions" with the addition "unless ou know how to fix and report problems" (it seems that you fall under that clause)

Originally Posted by Jonathan

I have moved my simulations from 2.1.1 / swak for 2.1.1 onto 1.6-ext / swak that comes with the nextRelease branch (0.2.4), and i am struggling (even having gotten it to compile as per above), to get my simulations to run.

Time = 1

[1] swak4Foam: Allocating new repository for sampledGlobalVariables
[3] swak4Foam: Allocating new repository for sampledGlobalVariables
[0] swak4Foam: Allocating new repository for sampledGlobalVariables
[2] swak4Foam: Allocating new repository for sampledGlobalVariables
DILUPBiCG:  Solving for Urelx, Initial residual = 0.0544779267115, Final residual = 0.000849955324891, No Iterations 1
DILUPBiCG:  Solving for Urely, Initial residual = 0.0185173067949, Final residual = 0.000154956162127, No Iterations 1
DILUPBiCG:  Solving for Urelz, Initial residual = 0.0156236887839, Final residual = 0.0001311641489, No Iterations 1
GAMG:  Solving for p, Initial residual = 0.936372869807, Final residual = 0.00751389308468, No Iterations 20
time step continuity errors : sum local = 2.99327913032, global = -0.625890992833, cumulative = -0.625890992833
[bergh01:3619] *** An error occurred in MPI_Recv
[bergh01:3619] *** on communicator MPI_COMM_WORLD
[bergh01:3619] *** MPI_ERR_TRUNCATE: message truncated
[bergh01:3619] *** MPI_ERRORS_ARE_FATAL (your MPI job will now abort)
Inconsistency detected by ld.so: dl-close.c: 759: _dl_close: Assertion `map->l_init_called' failed!
Inconsistency detected by ld.so: dl-close.c: 759: _dl_close: Assertion `map->l_init_called' failed!
Inconsistency detected by ld.so: dl-close.c: 759: _dl_close: Assertion `map->l_init_called' failed!
Inconsistency detected by ld.so: dl-close.c: 759: _dl_close: Assertion `map->l_init_called' failed!

Pfu. swak doesn't go down to this level of MPI to get this kind of error by itself. Usual reasons why this kind of error is seen is "OF was upgraded and recompiled but the swak-installation was not".

If you pull a new OF-version and recompile it ALWAYS recompile 3rd-party software that depends on OF

Originally Posted by Jonathan

i just want to confirm whether there is something i am doing wrong since i've changed versions (from 2.1.1 to 1.6-ext) and whether you "know" whether it should work with the nextRelease branch!

apologies for the long, somewhat garbled message! its been a long day!

best regards and many thanks
Jonathan

[Jonathan]

Thanks very much Bernhard,

its much appreciated.

best regards
jonathan

Originally Posted by gschaider

<blush>

The problem that you experienced is because 1.6-ext-nextRelease is a moving target. Last month the development version (an the last release) of swak compiled fine with it.

Last release of swak compiled with last release of 1.6-ext. That is all I can say. Next release of swak will compile with whatever is released at that time.

So in general I'd say "Only use released versions" with the addition "unless ou know how to fix and report problems" (it seems that you fall under that clause)

Pfu. swak doesn't go down to this level of MPI to get this kind of error by itself. Usual reasons why this kind of error is seen is "OF was upgraded and recompiled but the swak-installation was not".

If you pull a new OF-version and recompile it ALWAYS recompile 3rd-party software that depends on OF

[Daniel_Khazaei]

I am also trying to compile nextRelease branch of OpenFOAM-1.6, but I have a problem with compiling, I get the following error:

make: Nothing to be done for `all'.
+ wmakePrintBuild -check
same version as previous build
+ wmakeLnInclude OpenFOAM
+ wmakeLnInclude meshTools
+ wmakeLnInclude OSspecific/POSIX
+ Pstream/Allwmake
+ wmake libso dummy
'/opt/OpenFOAM/OpenFOAM-1.6-nextRelease/lib/linux64Gcc44DPOpt/dummy/libPstream.so' is up to date.
+ set +x

Note: ignore spurious warnings about missing mpicxx.h headers
+ WM_OPTIONS=linux64Gcc44DPOptSYSTEMOPENMPI
+ wmake libso mpi
'/opt/OpenFOAM/OpenFOAM-1.6-nextRelease/lib/linux64Gcc44DPOpt/openmpi-system/libPstream.so' is up to date.
+ wmake libo OSspecific/POSIX
'/opt/OpenFOAM/OpenFOAM-1.6-nextRelease/lib/linux64Gcc44DPOpt/libOSspecific.o' is up to date.
+ wmake libso OpenFOAM
SOURCE=global/global.Cver ; sed -e 's/VERSION_STRING/1.6-nextRelease/' -e 's/BUILD_STRING/1.6-nextRelease-b3be3f802467/' $SOURCE > Make/linux64Gcc44DPOpt/global.C; g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-40 -I/opt/OpenFOAM/OpenFOAM-1.6-nextRelease/ThirdParty/zlib-1.2.3 -IlnInclude -I. -I/opt/OpenFOAM/OpenFOAM-1.6-nextRelease/src/OpenFOAM/lnInclude -I/opt/OpenFOAM/OpenFOAM-1.6-nextRelease/src/OSspecific/POSIX/lnInclude   -fPIC -c Make/linux64Gcc44DPOpt/global.C -o Make/linux64Gcc44DPOpt/global.o
SOURCE=primitives/Lists/VectorNLists.C ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-40 -I/opt/OpenFOAM/OpenFOAM-1.6-nextRelease/ThirdParty/zlib-1.2.3 -IlnInclude -I. -I/opt/OpenFOAM/OpenFOAM-1.6-nextRelease/src/OpenFOAM/lnInclude -I/opt/OpenFOAM/OpenFOAM-1.6-nextRelease/src/OSspecific/POSIX/lnInclude   -fPIC -c $SOURCE -o Make/linux64Gcc44DPOpt/VectorNLists.o
In file included from lnInclude/VectorSpaceI.H:29:0,
                 from lnInclude/VectorSpace.H:167,
                 from lnInclude/VectorN.H:41,
                 from lnInclude/vector2.H:40,
                 from lnInclude/VectorNFieldTypes.H:34,
                 from primitives/Lists/VectorNLists.H:36,
                 from primitives/Lists/VectorNLists.C:30:
lnInclude/VectorSpaceM.H: In static member function ‘static void VectorSpaceOps<N, I>::eqOp(V1&, const V2&, EqOp) [with V1 = Foam::VectorSpace<Foam::TensorN<double, 6>, double, 36>, V2 = Foam::VectorSpace<Foam::TensorN<double, 6>, double, 36>, EqOp = Foam::eqOp<double>, int N = 36, int I = 33]’:
lnInclude/VectorSpaceM.H:27:9: error: template instantiation depth exceeds maximum of 40 (use -ftemplate-depth= to increase the maximum) instantiating ‘VectorSpaceOps<36, 33>::endLoop’
lnInclude/VectorSpaceM.H:27:9:   recursively instantiated from ‘static void VectorSpaceOps<N, I>::eqOp(V1&, const V2&, EqOp) [with V1 = Foam::VectorSpace<Foam::TensorN<double, 6>, double, 36>, V2 = Foam::VectorSpace<Foam::TensorN<double, 6>, double, 36>, EqOp = Foam::eqOp<double>, int N = 36, int I = 1]’
lnInclude/VectorSpaceM.H:27:9:   instantiated from ‘static void VectorSpaceOps<N, I>::eqOp(V1&, const V2&, EqOp) [with V1 = Foam::VectorSpace<Foam::TensorN<double, 6>, double, 36>, V2 = Foam::VectorSpace<Foam::TensorN<double, 6>, double, 36>, EqOp = Foam::eqOp<double>, int N = 36, int I = 0]’
lnInclude/VectorSpaceI.H:197:5:   instantiated from ‘void Foam::VectorSpace<Form, Cmpt, nCmpt>::operator=(const Foam::VectorSpace<Form, Cmpt, nCmpt>&) [with Form = Foam::TensorN<double, 6>, Cmpt = double, int nCmpt = 36]’
lnInclude/TensorN.H:60:7:   instantiated from ‘Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::List<T>&) [with T = Foam::TensorN<double, 6>]’
lnInclude/ListIO.C:41:5:   instantiated from ‘Foam::List<T>::List(Foam::Istream&) [with T = Foam::TensorN<double, 6>]’
lnInclude/token.H:227:17:   instantiated from ‘Foam::token::Compound<T>::Compound(Foam::Istream&) [with T = Foam::List<Foam::TensorN<double, 6> >]’
lnInclude/token.H:146:9:   instantiated from ‘static Foam::autoPtr<Foam::token::compound> Foam::token::compound::addIstreamConstructorToTable<compoundType>::New(Foam::Istream&) [with compoundType = Foam::token::Compound<Foam::List<Foam::TensorN<double, 6> > >]’
lnInclude/token.H:153:1:   instantiated from ‘Foam::token::compound::addIstreamConstructorToTable<compoundType>::addIstreamConstructorToTable(const Foam::word&) [with compoundType = Foam::token::Compound<Foam::List<Foam::TensorN<double, 6> > >]’
primitives/Lists/VectorNLists.C:43:1:   instantiated from here

lnInclude/VectorSpaceM.H:27:9: error: template instantiation depth exceeds maximum of 40 (use -ftemplate-depth= to increase the maximum) instantiating ‘VectorSpaceOps<36, 33>::endLoop’
lnInclude/VectorSpaceM.H:27:9:   recursively instantiated from ‘static void VectorSpaceOps<N, I>::eqOp(V1&, const V2&, EqOp) [with V1 = Foam::VectorSpace<Foam::TensorN<double, 6>, double, 36>, V2 = Foam::VectorSpace<Foam::TensorN<double, 6>, double, 36>, EqOp = Foam::eqOp<double>, int N = 36, int I = 1]’
lnInclude/VectorSpaceM.H:27:9:   instantiated from ‘static void VectorSpaceOps<N, I>::eqOp(V1&, const V2&, EqOp) [with V1 = Foam::VectorSpace<Foam::TensorN<double, 6>, double, 36>, V2 = Foam::VectorSpace<Foam::TensorN<double, 6>, double, 36>, EqOp = Foam::eqOp<double>, int N = 36, int I = 0]’
lnInclude/VectorSpaceI.H:197:5:   instantiated from ‘void Foam::VectorSpace<Form, Cmpt, nCmpt>::operator=(const Foam::VectorSpace<Form, Cmpt, nCmpt>&) [with Form = Foam::TensorN<double, 6>, Cmpt = double, int nCmpt = 36]’
lnInclude/TensorN.H:60:7:   instantiated from ‘Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::List<T>&) [with T = Foam::TensorN<double, 6>]’
lnInclude/ListIO.C:41:5:   instantiated from ‘Foam::List<T>::List(Foam::Istream&) [with T = Foam::TensorN<double, 6>]’
lnInclude/token.H:227:17:   instantiated from ‘Foam::token::Compound<T>::Compound(Foam::Istream&) [with T = Foam::List<Foam::TensorN<double, 6> >]’
lnInclude/token.H:146:9:   instantiated from ‘static Foam::autoPtr<Foam::token::compound> Foam::token::compound::addIstreamConstructorToTable<compoundType>::New(Foam::Istream&) [with compoundType = Foam::token::Compound<Foam::List<Foam::TensorN<double, 6> > >]’
lnInclude/token.H:153:1:   instantiated from ‘Foam::token::compound::addIstreamConstructorToTable<compoundType>::addIstreamConstructorToTable(const Foam::word&) [with compoundType = Foam::token::Compound<Foam::List<Foam::TensorN<double, 6> > >]’
primitives/Lists/VectorNLists.C:43:1:   instantiated from here

lnInclude/VectorSpaceM.H:27:9: error: the value of ‘VectorSpaceOps<36, 33>::endLoop’ is not usable in a constant expression
lnInclude/VectorSpaceM.H:7:48: note: ‘VectorSpaceOps<36, 33>::endLoop’ was not initialized with a constant expression
lnInclude/VectorSpaceM.H:27:9: note: in template argument for type ‘int’ 
lnInclude/VectorSpaceM.H:27:9: error: the value of ‘VectorSpaceOps<36, 33>::endLoop’ is not usable in a constant expression
lnInclude/VectorSpaceM.H:7:48: note: ‘VectorSpaceOps<36, 33>::endLoop’ was not initialized with a constant expression
lnInclude/VectorSpaceM.H:27:9: note: in template argument for type ‘int’ 
lnInclude/VectorSpaceM.H: In static member function ‘static void VectorSpaceOps<N, I>::eqOp(V1&, const V2&, EqOp) [with V1 = Foam::VectorSpace<Foam::TensorN<double, 8>, double, 64>, V2 = Foam::VectorSpace<Foam::TensorN<double, 8>, double, 64>, EqOp = Foam::eqOp<double>, int N = 64, int I = 33]’:
lnInclude/VectorSpaceM.H:27:9: error: template instantiation depth exceeds maximum of 40 (use -ftemplate-depth= to increase the maximum) instantiating ‘VectorSpaceOps<64, 33>::endLoop’
lnInclude/VectorSpaceM.H:27:9:   recursively instantiated from ‘static void VectorSpaceOps<N, I>::eqOp(V1&, const V2&, EqOp) [with V1 = Foam::VectorSpace<Foam::TensorN<double, 8>, double, 64>, V2 = Foam::VectorSpace<Foam::TensorN<double, 8>, double, 64>, EqOp = Foam::eqOp<double>, int N = 64, int I = 1]’
lnInclude/VectorSpaceM.H:27:9:   instantiated from ‘static void VectorSpaceOps<N, I>::eqOp(V1&, const V2&, EqOp) [with V1 = Foam::VectorSpace<Foam::TensorN<double, 8>, double, 64>, V2 = Foam::VectorSpace<Foam::TensorN<double, 8>, double, 64>, EqOp = Foam::eqOp<double>, int N = 64, int I = 0]’
lnInclude/VectorSpaceI.H:197:5:   instantiated from ‘void Foam::VectorSpace<Form, Cmpt, nCmpt>::operator=(const Foam::VectorSpace<Form, Cmpt, nCmpt>&) [with Form = Foam::TensorN<double, 8>, Cmpt = double, int nCmpt = 64]’
lnInclude/TensorN.H:60:7:   instantiated from ‘Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::List<T>&) [with T = Foam::TensorN<double, 8>]’
lnInclude/ListIO.C:41:5:   instantiated from ‘Foam::List<T>::List(Foam::Istream&) [with T = Foam::TensorN<double, 8>]’
lnInclude/token.H:227:17:   instantiated from ‘Foam::token::Compound<T>::Compound(Foam::Istream&) [with T = Foam::List<Foam::TensorN<double, 8> >]’
lnInclude/token.H:146:9:   instantiated from ‘static Foam::autoPtr<Foam::token::compound> Foam::token::compound::addIstreamConstructorToTable<compoundType>::New(Foam::Istream&) [with compoundType = Foam::token::Compound<Foam::List<Foam::TensorN<double, 8> > >]’
lnInclude/token.H:153:1:   instantiated from ‘Foam::token::compound::addIstreamConstructorToTable<compoundType>::addIstreamConstructorToTable(const Foam::word&) [with compoundType = Foam::token::Compound<Foam::List<Foam::TensorN<double, 8> > >]’
primitives/Lists/VectorNLists.C:43:1:   instantiated from here

lnInclude/VectorSpaceM.H:27:9: error: template instantiation depth exceeds maximum of 40 (use -ftemplate-depth= to increase the maximum) instantiating ‘VectorSpaceOps<64, 33>::endLoop’
lnInclude/VectorSpaceM.H:27:9:   recursively instantiated from ‘static void VectorSpaceOps<N, I>::eqOp(V1&, const V2&, EqOp) [with V1 = Foam::VectorSpace<Foam::TensorN<double, 8>, double, 64>, V2 = Foam::VectorSpace<Foam::TensorN<double, 8>, double, 64>, EqOp = Foam::eqOp<double>, int N = 64, int I = 1]’
lnInclude/VectorSpaceM.H:27:9:   instantiated from ‘static void VectorSpaceOps<N, I>::eqOp(V1&, const V2&, EqOp) [with V1 = Foam::VectorSpace<Foam::TensorN<double, 8>, double, 64>, V2 = Foam::VectorSpace<Foam::TensorN<double, 8>, double, 64>, EqOp = Foam::eqOp<double>, int N = 64, int I = 0]’
lnInclude/VectorSpaceI.H:197:5:   instantiated from ‘void Foam::VectorSpace<Form, Cmpt, nCmpt>::operator=(const Foam::VectorSpace<Form, Cmpt, nCmpt>&) [with Form = Foam::TensorN<double, 8>, Cmpt = double, int nCmpt = 64]’
lnInclude/TensorN.H:60:7:   instantiated from ‘Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::List<T>&) [with T = Foam::TensorN<double, 8>]’
lnInclude/ListIO.C:41:5:   instantiated from ‘Foam::List<T>::List(Foam::Istream&) [with T = Foam::TensorN<double, 8>]’
lnInclude/token.H:227:17:   instantiated from ‘Foam::token::Compound<T>::Compound(Foam::Istream&) [with T = Foam::List<Foam::TensorN<double, 8> >]’
lnInclude/token.H:146:9:   instantiated from ‘static Foam::autoPtr<Foam::token::compound> Foam::token::compound::addIstreamConstructorToTable<compoundType>::New(Foam::Istream&) [with compoundType = Foam::token::Compound<Foam::List<Foam::TensorN<double, 8> > >]’
lnInclude/token.H:153:1:   instantiated from ‘Foam::token::compound::addIstreamConstructorToTable<compoundType>::addIstreamConstructorToTable(const Foam::word&) [with compoundType = Foam::token::Compound<Foam::List<Foam::TensorN<double, 8> > >]’
primitives/Lists/VectorNLists.C:43:1:   instantiated from here

lnInclude/VectorSpaceM.H:27:9: error: the value of ‘VectorSpaceOps<64, 33>::endLoop’ is not usable in a constant expression
lnInclude/VectorSpaceM.H:7:48: note: ‘VectorSpaceOps<64, 33>::endLoop’ was not initialized with a constant expression
lnInclude/VectorSpaceM.H:27:9: note: in template argument for type ‘int’ 
lnInclude/VectorSpaceM.H:27:9: error: the value of ‘VectorSpaceOps<64, 33>::endLoop’ is not usable in a constant expression
lnInclude/VectorSpaceM.H:7:48: note: ‘VectorSpaceOps<64, 33>::endLoop’ was not initialized with a constant expression
lnInclude/VectorSpaceM.H:27:9: note: in template argument for type ‘int’ 
make: *** [Make/linux64Gcc44DPOpt/VectorNLists.o] Error 1
make: *** Waiting for unfinished jobs....

[Daniel_Khazaei]

I have fixed the above problem by increasing the -ftemplate-depth from 40 to 80 in the c++ file in the following directory:

/opt/OpenFOAM/OpenFOAM-1.6-nextRelease/wmake/rules/linux64Gcc44

does it have any side effects?

I did not have the same problem when I was compiling OpenFOAM-1.6ext.

[gschaider]

Originally Posted by Daniel_Khazaei

I have fixed the above problem by increasing the -ftemplate-depth from 40 to 80 in the c++ file in the following directory:

/opt/OpenFOAM/OpenFOAM-1.6-nextRelease/wmake/rules/linux64Gcc44

does it have any side effects?

Yeah. It make 1.6-ext compile

Seriously: No. The only reason this is set to a low value is because usually code doesn't need it and it potentially uses more memory DURING COMPILATION

Originally Posted by Daniel_Khazaei

I did not have the same problem when I was compiling OpenFOAM-1.6ext.

[Jonathan]

Hi Daniel,

I needed to make this change as well in order to get my source to compile.

I just wonder whether you would mind letting me know whether you managed to get everything running well once you got it compiled? I had issues running in parallel with swak4Foam (groovyBC), but couldnt figure out whether the problem was with my install or the source which is still developing.

many thanks and best regards
Jonathan

Originally Posted by Daniel_Khazaei

I have fixed the above problem by increasing the -ftemplate-depth from 40 to 80 in the c++ file in the following directory:

/opt/OpenFOAM/OpenFOAM-1.6-nextRelease/wmake/rules/linux64Gcc44

does it have any side effects?

I did not have the same problem when I was compiling OpenFOAM-1.6ext.

[Daniel_Khazaei]

Originally Posted by Jonathan

Hi Daniel,

I needed to make this change as well in order to get my source to compile.

I just wonder whether you would mind letting me know whether you managed to get everything running well once you got it compiled? I had issues running in parallel with swak4Foam (groovyBC), but couldnt figure out whether the problem was with my install or the source which is still developing.

many thanks and best regards
Jonathan

Hello Jonathan

I have still some problems with swak4Foam compilation.
I have fixed the problem you have mentioned but there is another problem that I have not fixed it yet. It complains about a 4th order symmetry tensor(pointpatch....)

So I can not tell if groovyBC is working fine in parallel or not.

Although I have tested one of solidMechanics solvers in parallel without any problems.

I will try to fix that error and test a parallel case with groovyBC and let you know.

Regards

[Daniel_Khazaei]

OK, I have fixed that problem to make swak4Foam compatible with nextRelease_philipc branch of OpenFOAM-1.6ext.

I have to add the following lines to groovyBCPointPatchFields.H:

    typedef groovyBCPointPatchField<symmTensor4thOrder> groovyBCPointPatchSymmTensor4thOrderField;
    typedef groovyBCPointPatchField<diagTensor> groovyBCPointPatchDiagTensorField;

Now I will try to test a parallel run of groovyBC.
tell me if you have any special cases in mind.

----------------

I have tested one of swak4Foam examples and I can confirm that the problem is there:

Selecting incompressible transport model Newtonian
Selecting turbulence model type RASModel
Selecting RAS turbulence model kEpsilon
kEpsilonCoeffs
{
    Cmu             0.09;
    C1              1.44;
    C2              1.92;
    sigmaEps        1.3;
}


Starting time loop

Courant Number mean: 0 max: 0 velocity magnitude: 0
--> FOAM Warning : 
    From function dlLibraryTable::open(const dictionary& dict, const word& libsEntry, const TablePtr tablePtr)
    in file lnInclude/dlLibraryTableTemplates.C at line 68
    library "libsampling.so" did not introduce any new entries

--> FOAM Warning : 
    From function simpleFunctionObject::simpleFunctionObject
    in file simpleFunctionObject/simpleFunctionObject.C at line 108
    'outputControlMode' not found in flows
Assuming: timestep
--> FOAM Warning : 
    From function simpleFunctionObject::simpleFunctionObject
    in file simpleFunctionObject/simpleFunctionObject.C at line 116
    'outputInterval' not found in flows
Assuming: 1
Time = 0.0005

[1] swak4Foam: Allocating new repository for sampledGlobalVariables
[0] swak4Foam: Allocating new repository for sampledGlobalVariables
DILUPBiCG:  Solving for Ux, Initial residual = 1, Final residual = 0.0617906, No Iterations 4
DILUPBiCG:  Solving for Uy, Initial residual = 1, Final residual = 0.0992882, No Iterations 2
DILUPBiCG:  Solving for Uz, Initial residual = 1, Final residual = 0.0604715, No Iterations 4
GAMG:  Solving for p, Initial residual = 1, Final residual = 0.00924619, No Iterations 8
time step continuity errors : sum local = 1.87115e-07, global = -2.97353e-08, cumulative = -2.97353e-08
[isengard-P5QL-PRO:13873] *** An error occurred in MPI_Recv
[isengard-P5QL-PRO:13873] *** on communicator MPI_COMM_WORLD
[isengard-P5QL-PRO:13873] *** MPI_ERR_TRUNCATE: message truncated
[isengard-P5QL-PRO:13873] *** MPI_ERRORS_ARE_FATAL (your MPI job will now abort)
Inconsistency detected by ld.so: dl-close.c: 759: _dl_close: Assertion `map->l_init_called' failed!
Inconsistency detected by ld.so: dl-close.c: 759: _dl_close: Assertion `map->l_init_called' failed!
--------------------------------------------------------------------------
mpirun has exited due to process rank 0 with PID 13873 on
node isengard-P5QL-PRO exiting without calling "finalize". This may
have caused other processes in the application to be
terminated by signals sent by mpirun (as reported here).
--------------------------------------------------------------------------
[isengard-P5QL-PRO:13871] 1 more process has sent help message help-mpi-errors.txt / mpi_errors_are_fatal
[isengard-P5QL-PRO:13871] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages