[KingKraut]

Hi all,

I am currently trying to compile swak4Foam with RapidCFD. The system I am using is Scientific Linux 6.7.

I get the following error, when running ./Allwmake from within the folder swak4Foam:

make: *** No rule to make target `FieldValueExpressionParser.dep', needed by `Make/linux64NvccDPOpt/dependencies'. Stop.
Parser library did not compile OK. No sense continuing as everything else depends on it

I attached the full output of the command and the log from ./maintenanceScripts/compileRequirements.sh, too. Apart from that I explicitley compiled m4 version 1.4.17, as described here http://openfoamwiki.net/index.php/In...g_dependencies.
So the settings seem to be alright, I think.

I googled the error, but all I could find, was the instructions I already tried...
I am a little stuck here right now, but to me the error seems to be not caused by the combination with RapidCFD but rather some options I just did not yet set right in swak4Foam.

Can anybody point me into the right direction? Any idea, which way I could go from here?

Thanks a lot for looking into this!!

Best regards
Johannes

[KingKraut]

Dear all,

Ok, I tried a different version of swak4Foam. Instead of 0.4.0 I used version 0.3.2 (which worked fine for an installation of OF222 on the same system).

The error produced now is different (but later in the process!). I attached the output. The error message at the end is the following:

In file included from helpers/printSwakVersion.C:44:0:
lnInclude/swak.H:50:30: error: operator '<' has no left operand
#if (FOAM_VERSION4SWAK_MAJOR < 2)
^
lnInclude/swak.H:71:32: error: operator '>' has no left operand
#if !((FOAM_VERSION4SWAK_MAJOR > 1) || (FOAM_VERSION4SWAK_MINOR > 6))
^
lnInclude/swak.H:76:49: error: operator '||' has no right operand
#if defined(FOAM_DEV) || FOAM_VERSION4SWAK_MAJOR>1
^
make: *** [Make/linux64NvccDPOpt/printSwakVersion.o] Error 1
Parser library did not compile OK. No sense continuing as everything else depends on it

Requirements for Library not satisfied. I see no sense in going on
Check the README before you go on to ask. And search: Most likely your problem occured to 5 other people before and has been solved on the MessageBoard

I had a look at the files printSwakVersion.C and swak.H in /swak4Foam/Libraries/swak4FoamParsers/helpers and to me it seems, as if it is looking for the name of my OpenFOAM-version. Since RapidCFD has a different name, this might cause the problem here? Does this make sense?

If anyone has an idea, how I can set this correctly and go on compiling with swak4Foam, this would be of great help. RapidCFD is based on OF231, so I guess I need to tell the compilation process somehow that it is for version OF231...
Or is my thinking completely in the wrong direction?

Thanks a lot for looking into this!!

Best regards
Johannes

[KingKraut]

Nothing? :-(

[KingKraut]

I am currently thinking about reinstalling RapidCFD, however this time in the folder structure of OpenFOAM, i.e. with the names

export WM_PROJECT=OpenFOAM
export WM_PROJECT_VERSION=2.3.1

instead of

export WM_PROJECT=RapidCFD
export WM_PROJECT_VERSION=dev

as it is default for RapidCFD...

However this option seems a bit crude to me - not to mention, that I am not at all sure, this will work...
Maybe there is another way to alter this version check in the installation of swak4Foam? To let it know, that it is version OF231 and not something not known like RapidCFD-dev?

Thanks for all advice!

[wyldckat]

Quick answer: Sorry for the late response, but I didn't have the time needed to look into this myself.

Given that you've provided the details as you went along, you seem to be close to solving the problem. Furthermore, it looks like the trick should be easier than what you're planning!
If I'm not mistaken, you simply need to use those 2 lines inside the "swakConfiguration" file and it should work well as a workaround! For example, by running inside the swak4Foam folder:

echo export WM_PROJECT=OpenFOAM >> swakConfiguration
echo export WM_PROJECT_VERSION=2.3.1 >> swakConfiguration

Then run:

./Allwclean
./Allwmake > log.make 2>&1

At least up to a point where it might break due to other missing files...

[gschaider]

Originally Posted by wyldckat

Quick answer: Sorry for the late response, but I didn't have the time needed to look into this myself.

Given that you've provided the details as you went along, you seem to be close to solving the problem. Furthermore, it looks like the trick should be easier than what you're planning!
If I'm not mistaken, you simply need to use those 2 lines inside the "swakConfiguration" file and it should work well as a workaround! For example, by running inside the swak4Foam folder:

echo export WM_PROJECT=OpenFOAM >> swakConfiguration
echo export WM_PROJECT_VERSION=2.3.1 >> swakConfiguration

Then run:

./Allwclean
./Allwmake > log.make 2>&1

At least up to a point where it might break due to other missing files...

That's a very creative way of using swakConfiguration to work around that problem. I'll have a look and add something like "Error: your $WM_PROJECT is not supported for swak4Foam (only OpenFOAM and foam). Please set SWAK_WM_PROJECT_EQUIV and SWAK_WM_PROJECT_VERSION_EQUIV to the OpenFOAM/foam-version your foam-derivate is equivalent too" and use these variables instead for obscure Foam-versions

[KingKraut]

Thanks a lot for the hints!!!
This worked very well and saved me from reinstalling RapidCFD with a "new" name, which did not work in the first go anyway...

The installation of swak4Foam now went further, but crashed again. The error occurring now is:

nvcc fatal : Don't know what to do with 'Make/linux64NvccDPOpt/FieldValueExpressionParser.C'
make: *** [Make/linux64NvccDPOpt/FieldValueExpressionParser.o] Error 1

I also attached the full log_file.
I again looked for the file FieldValueExpressionParser.C in /home/martens_j/RapidCFD/martens-dev/swak4Foam/Libraries/swak4FoamParsers/Make/linux64NvccDPOpt, but unfortunately here I don't quite see what's happening anymore.

Thanks again for looking into this! I appreciate this very much!!

Best regards

[gschaider]

Originally Posted by KingKraut

Thanks a lot for the hints!!!
This worked very well and saved me from reinstalling RapidCFD with a "new" name, which did not work in the first go anyway...

The installation of swak4Foam now went further, but crashed again. The error occurring now is:
I also attached the full log_file.
I again looked for the file FieldValueExpressionParser.C in /home/martens_j/RapidCFD/martens-dev/swak4Foam/Libraries/swak4FoamParsers/Make/linux64NvccDPOpt, but unfortunately here I don't quite see what's happening anymore.

Thanks again for looking into this! I appreciate this very much!!

Best regards

Somehow the nvcc does not know how to compile the C++-file generated by bison. I can only guess what might be the problem:

1. for some reason the file isn't there. You said you looked but I'm not quite clear whether you found it
2. Somehow the options of the nvcc-call are wrong. Try going to the swak4FoamParsers-directory. Copy the last compile command (the one starting with "SOURCE=FieldValueExpressionParser.yy ;" to the command line and trying it out. Also just the part that starts with "nvcc". See what differences there are compared to the "successful" nvcc-calls

But I havn't got that compiler and therefor can't try this myself. If you get that call working get back to me and we can work out how to fix this permanently

[KingKraut]

Thanks a lot for the response.
Sorry, for being unclear about the presence of the file FieldValueExpressionParser.C. It is present in the directory /home/martens_j/RapidCFD/martens-dev/swak4Foam/Libraries/swak4FoamParsers/Make/linux64NvccDPOpt where it should be.

Thanks again for the help! I will try as you suggested and get back with the outcome!

Best regards
Johannes

[KingKraut]

I just tried the full command

SOURCE=FieldValueExpressionParser.yy ; rm -f Make/linux64NvccDPOpt/FieldValueExpressionParser.C Make/linux64NvccDPOpt/FieldValueExpressionParser.tab.hh; mkdir $$; cd $$; [ -n "" ] && sleep 30; bison -ra -v -d ../$SOURCE ; mv *.tab.cc ../Make/linux64NvccDPOpt/FieldValueExpressionParser.C ; sed -i.bak "s/position.hh/FieldValueExpressionParser_position.hh/" location.hh ; mv location.hh ../lnInclude/FieldValueExpressionParser_location.hh ; mv stack.hh ../lnInclude/FieldValueExpressionParser_stack.hh ; mv position.hh ../lnInclude/FieldValueExpressionParser_position.hh ; sed -i.bak "s/stack.hh/FieldValueExpressionParser_stack.hh/;s/location.hh/FieldValueExpressionParser_location.hh/" FieldValueExpressionParser.tab.hh ;mv *.hh ../lnInclude ; touch -r ../$SOURCE ../lnInclude/FieldValueExpressionParser*.hh ; cd ..; rm -r $$; if [ -z "" ]; then echo -e "\n\nIf compilation of the grammers takes prohibitivly long set SWAK_COMPILE_GRAMMAR_OPTION to something like -O1\n\n" ; fi; nvcc -Xptxas -dlcm=cg -m64 -arch=sm_30 -Dlinux64 -DWM_DP -Xcompiler -Wall -Xcompiler -Wextra -Xcompiler -Wno-unused-parameter -Xcompiler -Wno-vla -Xcudafe "--diag_suppress=null_reference" -Xcudafe "--diag_suppress=subscript_out_of_range" -Xcudafe "--diag_suppress=extra_semicolon" -Xcudafe "--diag_suppress=partial_override" -Xcudafe "--diag_suppress=implicit_return_from_non_void_functi on" -Xcudafe "--diag_suppress=virtual_function_decl_hidden" -O3 -DNoRepository -D__RESTRICT__='__restrict__' -IMake/linux64NvccDPOpt -I/opt/RapidCFD/RapidCFD-dev/src/finiteVolume/lnInclude -I/opt/RapidCFD/RapidCFD-dev/src/sampling/lnInclude -I/opt/RapidCFD/RapidCFD-dev/src/fileFormats/lnInclude -I/opt/RapidCFD/RapidCFD-dev/src/triSurface/lnInclude -I/opt/RapidCFD/RapidCFD-dev/src/surfMesh/lnInclude -I/opt/RapidCFD/RapidCFD-dev/src/lagrangian/basic/lnInclude -I/opt/RapidCFD/RapidCFD-dev/src/meshTools/lnInclude -IlnInclude -I. -I/opt/RapidCFD/RapidCFD-dev/src/OpenFOAM/lnInclude -I/opt/RapidCFD/RapidCFD-dev/src/OSspecific/POSIX/lnInclude -Xcompiler -fPIC -c Make/linux64NvccDPOpt/FieldValueExpressionParser.C -o Make/linux64NvccDPOpt/FieldValueExpressionParser.o

in the directory
/home/martens_j/RapidCFD/martens-dev/swak4Foam/Libraries/swak4FoamParsers.

Not much surprisingly this gave the same output as before. For both parts of the command...

I looked for differences in the call of the commands with the previous nvcc-commands and found the following flags

-x cu -D__HOST____DEVICE__='__host__ __device__'

,
that were called in the previous command of the Allwmake-logfile for makeSwakDataEntry.o.

I thus tried running the command with these options, too

SOURCE=FieldValueExpressionParser.yy ; rm -f Make/linux64NvccDPOpt/FieldValueExpressionParser.C Make/linux64NvccDPOpt/FieldValueExpressionParser.tab.hh; mkdir $$; cd $$; [ -n "" ] && sleep 30; bison -ra -v -d ../$SOURCE ; mv *.tab.cc ../Make/linux64NvccDPOpt/FieldValueExpressionParser.C ; sed -i.bak "s/position.hh/FieldValueExpressionParser_position.hh/" location.hh ; mv location.hh ../lnInclude/FieldValueExpressionParser_location.hh ; mv stack.hh ../lnInclude/FieldValueExpressionParser_stack.hh ; mv position.hh ../lnInclude/FieldValueExpressionParser_position.hh ; sed -i.bak "s/stack.hh/FieldValueExpressionParser_stack.hh/;s/location.hh/FieldValueExpressionParser_location.hh/" FieldValueExpressionParser.tab.hh ;mv *.hh ../lnInclude ; touch -r ../$SOURCE ../lnInclude/FieldValueExpressionParser*.hh ; cd ..; rm -r $$; if [ -z "" ]; then echo -e "\n\nIf compilation of the grammers takes prohibitivly long set SWAK_COMPILE_GRAMMAR_OPTION to something like -O1\n\n" ; fi; nvcc -Xptxas -dlcm=cg -m64 -arch=sm_30 -Dlinux64 -DWM_DP -Xcompiler -Wall -Xcompiler -Wextra -Xcompiler -Wno-unused-parameter -Xcompiler -Wno-vla -Xcudafe "--diag_suppress=null_reference" -Xcudafe "--diag_suppress=subscript_out_of_range" -Xcudafe "--diag_suppress=extra_semicolon" -Xcudafe "--diag_suppress=partial_override" -Xcudafe "--diag_suppress=implicit_return_from_non_void_functi on" -Xcudafe "--diag_suppress=virtual_function_decl_hidden" -O3 -DNoRepository -D__RESTRICT__='__restrict__' -IMake/linux64NvccDPOpt -I/opt/RapidCFD/RapidCFD-dev/src/finiteVolume/lnInclude -I/opt/RapidCFD/RapidCFD-dev/src/sampling/lnInclude -I/opt/RapidCFD/RapidCFD-dev/src/fileFormats/lnInclude -I/opt/RapidCFD/RapidCFD-dev/src/triSurface/lnInclude -I/opt/RapidCFD/RapidCFD-dev/src/surfMesh/lnInclude -I/opt/RapidCFD/RapidCFD-dev/src/lagrangian/basic/lnInclude -I/opt/RapidCFD/RapidCFD-dev/src/meshTools/lnInclude -IlnInclude -I. -I/opt/RapidCFD/RapidCFD-dev/src/OpenFOAM/lnInclude -I/opt/RapidCFD/RapidCFD-dev/src/OSspecific/POSIX/lnInclude -Xcompiler -fPIC -x cu -D__HOST____DEVICE__='__host__ __device__' -o Make/linux64NvccDPOpt/FieldValueExpressionParser.o -c $SOURCE

I am not sure, if this makes any sense at all. To be honest, I currently groping in the dark with this... However, this produced lots of errors (see the attached log)...

I will further look into this as soon as possible, just wanted to give it a quick try!

Thanks again for the suggestions and the help so far!!!

Best regards
Johannes

[KingKraut]

Sorry, forgot the attachment.

[wyldckat]

Greetings to all!

@Bernhard:

Originally Posted by gschaider

That's a very creative way of using swakConfiguration to work around that problem.

That was what I got at the 2nd iteration, based on Johannes' starting point


@Johannes: I was hoping the issues were fewer, so I didn't go into more details in the previous post. So here is a brief summary of what I know:

• I had a look into RapidCFD's code a few months ago, after exchanging a few emails with the author. I have to say that it looks like it's taking the right steps in the right direction, regarding how it hooks-up to the GPU.
• I saw some interesting details, where the code is using pragmas to let the compiler know where each method should be stationed: either on the CPU ("host") or on the GPU.
• So here's the problem, which I'm not sure how it's done by nvcc: there is a lot of code that is completely impractical to be run directly on the GPU.
• Which means, that there might have to be one or more methods or whole classes that need the necessary pragmas to state that the code must run on the CPU and not the GPU.

I do have plans to look into RapidCFD sometime in the future, but I have no idea when that will be. Therefore, I have two suggestions:

1. Contact the authors of RapidCFD as soon as possible. I have no idea if they will do this adaptation of swak4Foam for free or for a fee.
2. What exactly do you need swak4Foam for at the moment? I ask this, because if it's for fairly simple tasks, it might be faster to use the existing functionalities that RapidCFD inherited from OpenFOAM, instead of adapting swak4Foam to build with nvcc.

Best regards,
Bruno

[KingKraut]

Dear Bruno,

thanks again for your fast reply and the detailed answers!

I have already been in quite frequent contact with the authors of RapidCFD over the last few weeks, during the installation process of RapidCFD itself. I also asked about swak4Foam, but this has not yet been tackled. I will keep asking if there is interest in implementing this...

So far I am pretty satisfied with RapidCFD nonetheless!
I am not totally dependent on swak4Foam - however it is very, very convenient to use. I frequently use groovyBC in my simulations, since they just give more freedom in choice...

But I also think, that for me it will probably be easier to find a work-around within RapidCFD, rather than trying to get swak4Foam working with it - at least for the moment.

Nevertheless I am very interested in swak4Foam and would be very happy, if using this could be made possible within RapidCFD!!
I will certainly stay tuned on this topic!

Best regards
Johannes