Check that we can compile FluDAG along side user routines contained in $FLUPRO/usrmvmax

[makeclean]

We need to provide a way for users to compile their own source/variance reduction routines against FluDAG, it may be as simple as compiling them everytime and linking in their object files since the default files do nothing but return back to the main program.

• Need to check that we can compile user routines
• Need to ensure that this does not break our build

Check that our documentation is correct https://github.com/svalinn/DAGMC/tree/master/FluDAG#fluka-main, states that "It is not possible to use FLUKA's method of linking in user routines that can pass information to flukam_"

Am I misinterpreting what this sentence says?

[julamot]

I think that statement is wrong. I'll update the doc along once I've verified.

[julamot]

Doing the simplest thing and adding ${FLUPRO)/usermvax/mgdraw.f to the CMakefile, and adding ${FLUPRO}/flukapro as an include directory, it fails with a message saying that it doesn't know how to make '(CSLIM)'. This is a little odd, because it does find and include the three files in the list prior to (CSLIM)

[makeclean]

You'll need to build that with gfortran right?

Don't forget to include the 'includes' e.g.

gfortran usermvax/mgraw.f -I/data/opt/fluka/fluka/flukapro

On 05/20/2013 03:03 PM, Julie C. Zachman wrote:

Doing the simplest thing and adding ${FLUPRO)/usermvax/mgdraw.f to the CMakefile, and adding ${FLUPRO}/flukapro as an include directory, it fails with a message saying that it doesn't know how to make '(CSLIM)'. This is a little odd, because it does find and include the three files in the list prior to (CSLIM)

— Reply to this email directly or view it on GitHub https://github.com/svalinn/DAGMC/issues/78#issuecomment-18169132.

[julamot]

I have the line "SET (CMAKE_Fortran_Compiler gfortran)" in my CMakefile. And I have the line "include_directories(include ${MOAB_INCLUDE} ${FLUPRO}/flukapro)" as well. It is successfully including 3 fortran files from the $FLUPRO/flukapro directory, but it wants to "make" (CSLIM) and other includes. (CSLIM) has a COMMON block defined and I wonder if that's part of the problem.

[makeclean]

On 05/20/2013 03:14 PM, Julie C. Zachman wrote:

I have the line "SET (CMAKE_Fortran_Compiler gfortran)" in my CMakefile. And I have the line "include_directories(include ${MOAB_INCLUDE} ${FLUPRO}/flukapro)" as well. It is successfully including 3 fortran files from the $FLUPRO/flukapro directory, but it wants to "make" (CSLIM) and other includes. (CSLIM) has a COMMON block defined and I wonder if that's part of the problem.

— Reply to this email directly or view it on GitHub https://github.com/svalinn/DAGMC/issues/78#issuecomment-18169738.

If I just type

gfortran usermvax/mgdraw.f -I/data/opt/fluka/fluka/flukapro -L /data/opt/fluka/fluka/ -lflukahp

I get a fully functioning fluka executable

[makeclean]

Its the name of the include file that is mangling it I think, the following works fine

        program main_test
        implicit none
        integer bob
        include (BOBINC)
c        include '(CASLIM)'
        write(*,*) bob_val
        end program

(BOBINC) is in include/(BOBINC)

* example include file
        real::bob_val = 12.0

With the following cmake file cmake_minimum_required (VERSION 2.6)

enable_language (Fortran)
get_filename_component (Fortran_COMPILER_NAME ${CMAKE_Fortran_COMPILER} NAME)

set(extern_INCLUDE /data/opt/fluka/fluka/flukapro)
set(near_INCLUDE /home/davisa/ftest/include)
include_directories(${extern_INCLUDE} ${near_INCLUDE})

set(main-source_SRC main.f)
add_executable(main-source ${main-source_SRC})

(BOBINC) will fail, replacing it with bob_inc will work fine.

[makeclean]

Cmake is parsing the file with its own format, of which include ( stuff ) is valid syntax. Im trying to find a way that will stop Cmake parsing it.

[julamot]

Cmake works fine if the incude file is named with out parentheses. It appears as if cmake thinks a file with a name of format "(*)", e.g. "(DBLPRC)", is a target, which it doesn't know how to make.

[julamot]

In the $FLUPRO directory one can create the mgdraw object file with the command (similar to Andy's previous compile instruction) gfortran -o mgdraw.f.o -I./flukapro -L./ -lflukahp It might be possible to execute this command in cmake via its add_custom_command facility.

[julamot]

I have pushed a new branch, issue78_fludag, which is based off fludagwork and consists of the commit src/CMakeLists.txt. This file allows for compilation and linking of mgdraw.f in mainfludag.

It compiles, but it is not yet tested by running mainfludag.

[julamot]

I've tested this and mainfludag runs without error. This branch will be merged with the g1fix branch and the mainfludag tests for that fix can be run.

[makeclean]

Before you do could you test it with a usrsrc.f that I can provide you later? Its a custom neutron source, I will provide you with an apropriate input deck along with the source.

[makeclean]

Actually, ill pull it and post results here. Double confirmation of your fix and functionality. :)

[julamot]

I wasn't going to merge it with g1fix until I got g1fix rebased the way we want.

[makeclean]

FYI, on my system I had to reverse the order of the libraries in the CMakeList.txt file

 SET (moablibs ${MOAB_LIB_DIR}/libMOAB.so ${MOAB_LIB_DIR}/libdagmc.so)

Didnt work, complained that the final executable wouldnt link, however reversing them so Dag comes first

SET (moablibs ${MOAB_LIB_DIR}/libdagmc.so ${MOAB_LIB_DIR}/libMOAB.so)

Works fine, guess its since DAG need Moab? The other info you would need is I never use the cmake.local file, I always delete that from the cmake and then pass MOAB_HOME as an argument, eg

cmake ../src/ -DMOAB_HOME=<my path to moab>

[julamot]

Hmm, that's odd bout the library order - I definitely didn't get any problem.

As far as cmake.local, it's optional if you want to do -D that's fine, but either way works, and both are documented. Which reminds me, I have to fix up the documentation too.

[makeclean]

I confirm that this is working as intended, I expect neutrons at energies upto 1 GeV with the following distribution using the source I will include in a testing dir.

Using sensible.h5m and a modified version of spheres.inp having recompiled with my routine. I confirm functionality.

[makeclean]

I suggest we re-order the link line, even if im the only one to have problems I surely wont be the only one in future. If it fixes my problem and doesnt cause you any I suggest we do it.

[julamot]

Ok.

I've just pushed a copy of g1fix that has all your commits.

I'm about to merge and push a rebased g1fix that has just the code changes up to the one you mentioned, plus the last commit (which was a code change).

On May 21, 2013, at 7:12 PM, Andrew Davis notifications@github.com wrote:

I suggest we re-order the link line, even if im the only one to have problems I surely wont be the only one in future. If it fixes my problem and doesnt cause you any I suggest we do it.

— Reply to this email directly or view it on GitHub.

[julamot]

The branch for this issue needs to be rebased to fludagwork and merged before this can be closed.

[julamot]

I have rebased fludagwork to issue78_fludag and will push it forthwith. I am not issuing a pull request since it was assumed this had happened when Issue 78 was closed.