Project

General

Profile

Feature #990

G4Beamline Interface to MAUS

Added by Rogers, Chris over 11 years ago. Updated over 9 years ago.

Status:
Open
Priority:
Normal
Assignee:
Nugent, John
Category:
Simulation
Target version:
Future MAUS release
Start date:
15 May 2012
Due date:
% Done:

0%

Estimated time:
Workflow:
In Development

Description

Assigned to Leonova

The way I would probably work is:-

We put Marco's deck on bazaar to do version control and put this as a
    separate third party library. Putting the beamline deck on bazaar - I
    see this as crucial regardless of the rest.
    We include G4Beamline as a third party library in MAUS
    We write an input or mapper in MAUS to run particles through (depends
    what you want to do). This means you are bound by MAUS's release cycle,
    MAUS's quality control, etc - advantages and disadvantages to that.

The advantage is that you are automatically included in the MICE monte
carlo, you can use the MAUS configuration database interfaces, you can
use the MAUS test server. Also if we ever get round to parellelising
MAUS properly, you can take advantage of that.

Disadvantage is that you are bound by our style requirements and QA
requirements.

An alternative might be to include MAUS as a third party application and
use the cdb interface that way.

Another alternative might be to reimplement the geometry in CAD for
import in the general MICE CAD import stuff.

Files

MAUS_G4BL_Interface.pdf (109 KB) MAUS_G4BL_Interface.pdf Rogers, Chris, 15 May 2012 16:52
MAUS_G4BL_Interface.odt (18.6 KB) MAUS_G4BL_Interface.odt Rogers, Chris, 15 May 2012 16:52
build.log (10.4 KB) build.log coin build log Rajaram, Durga, 10 March 2014 09:49
G4BLoutput.txt (16 KB) G4BLoutput.txt Rajaram, Durga, 25 March 2014 04:05
diff.log (2.07 KB) diff.log Rajaram, Durga, 25 March 2014 16:22
G4BLoutput.txt (118 Bytes) G4BLoutput.txt Rajaram, Durga, 25 March 2014 18:18
sim.log (101 KB) sim.log Rajaram, Durga, 25 March 2014 18:18

Related issues

Follows MAUS - Feature #689: Specify G4Beamline interface to MAUSClosedRogers, Chris31 August 2011

Actions
#2

Updated by Rogers, Chris over 10 years ago

  • Assignee changed from Rogers, Chris to Nugent, John

John, have a look at this. Note that in the task specification it does say "weekly updates" which clearly was not done - meaning that now you have to pick it up without really seeing the history.

I note the existence of this branch:

https://code.launchpad.net/~maus-mappybeamlinesimulation/maus/devel

which may have some clues. I think the specification fits with what we discussed at geometry meeting yesterday, but please let me know if there are discrepancies.

#3

Updated by Rogers, Chris almost 10 years ago

John Nugent reports at GRID meeting 30th October 2013 that he has a functioning mapper that runs through the magnets to upstream of D2, but using hard coded magnet currents, and reads the particle data into MAUS.

#4

Updated by Rajaram, Durga over 9 years ago

Hi John,

A few things about the installation:

  • do not include the g4bl tgz file in the third_party/source. instead keep just the md5, provide a link to download the source tarball from, download it and verify the checksum on the tarball. see for e.g. the other installation scripts
  • g4beamline seems to want to build CHELP v2.1.1 and GEANT -- but these are already built as MAUS third parties, and there's no reason to rebuild them
  • you have modified the install_build_test.bash script in the parent directory. please use the "standard" install_build_test.bash from MAUS. You should not have to change anything other than third_party/build_all.bash [ which you have already done ]
  • there's a new version of g4beamline 2.16 [ from Jan 11, 2014 ] -- you might want to upgrade to that one, since it is based off of GEANT 4.9.6p02 which is the version MAUS uses as well.
#5

Updated by Rajaram, Durga over 9 years ago

Somehow this build error had gone past me earlier.
Coin refused to build on my machine and hence g4beamline build died.

G4beamline configuration complete.
Now do 'make'.

INFO: Make:

G4beamline build begun Mon Mar 10 04:36:51 CDT 2014   VERSION=2.12-durga
Building CLHEP...   Log is /home/durga/g4bl-devel/third_party/build/G4beamline-2.12-source/build/clhep/build.log
Building CLHEP complete.
Building Coin...    Log is /home/durga/g4bl-devel/third_party/build/G4beamline-2.12-source/build/coin/build.log
make: [build/coin/.complete] Error 1 (ignored)
Building Coin FAILED *****
make: *** [build/coin/.complete] Error 1
/home/durga/g4bl-devel/third_party/build/G4beamline-2.12-source/build/coin/build.log

Attached build.log from 

third_party/build/G4beamline-2.12-source/build/coin/

Looks like coin wants opengl. I think coin can be disabled by turning the visualization option off in the g4bl configure

FYI: my machine is a 64-bit SL6 system.

#6

Updated by Nugent, John over 9 years ago

Hi Durga,

I had previously set up the bash script to download G4BL at build time and included the md5 as you suggested however the webpage for G4BL is protected by a CAPTCHA preventing an automated download.

Removed the CLHEP and Geant build from G4bl.

Now switched to the standard install_build_test.bash script.

I have downloaded and built G4bl 2.16 on my own linux machine. Unfortunately whenever I run it it throws a segfault. This is not related to MAUS this is in my standalone G4bl installation. I have not been able to figure out why this occurs and so have used the latest working version that I have in the integration. If I figure out what the problem is I will update the G4bl version.

The coin build has been disabled.

I will put a new job on jenkins to test the new setup.

#7

Updated by Rajaram, Durga over 9 years ago

Hi John,

You can get it without a captcha from here:
http://www.muonsinternal.com/muons3/g4beamline/G4beamline-2.12-source.tgz

I played around a little bit with your latest version r717
Commenting out the coin, clhep, and geant4 in configure doesn't work
To disable the visual, I think all you have to do is modify 81..bash to do ./configure --disable-visual

Trying to avoid the clhep and geant rebuilds is messier than I expected
Turns out g4beamline builds against static geant4 objects
So the only options are to
a) make static geant4 libraries during the geant 4.9.6 build and then hack the g4beamline buld scripts to use them [ = messy ]
or
b) forget about it and let it rebuild geant

Option b) means an additional ~10 minutes [ on my machine ] to rebuild the geant4 static objects, which is not that big a deal.
My bigger concern was having g4beamline build against a different version of geant than what MAUS ships with.
But maybe we live with it [ for now ]

For the CLHEP build, in principle you can copy the libCLHEP-2.1.1.0.a archive from third_party/build/clhep-2.1.1.0/ but again it would require hacking the configure script and having it do that instead of rebuilding CLHEP.
But the CLHEP rebuild doesn't take long.

So, in the interest of keeping it simple and getting it integrated, let's forget about avoiding the clhep and geant rebuilds, and just disable COIN.
./configure --disable-visual
make

Let me know if you want me to get these things in

[ BTW, did you build it with coin visualization on your machine? If so, did you have to install additional packages? ]

#8

Updated by Nugent, John over 9 years ago

Hi Durga,

I have made all of these modifications and I am building a copy on my local machine as a test. I built with the coin visualisation on my system without any extra packages and have had no issues. I am using a SL5.9 64-bit.

#9

Updated by Rajaram, Durga over 9 years ago

Hi John,

I was able to build with your version r719
[ note I had to make some changes so that the MAUS version of ROOT gets used instead of having g4bl rebuild an older version ]

A couple of things:
1. running 

src/map/MapPyBeamlineSimulation/test_mappybeamlinesimulation.py
produces a bunch of output that clutters the MAUS_ROOT_DIR [ GVA1.txt, 0.trace.txt, 0.root, maus_beam_output.txt ] -- can you have the tests write them out the tmp directory?

2. I downloaded geometry id 13 from CDB and ran simulate_mice
  • enabled g4bl definition in ConfigurationDefaults
  • enabled MapPyBeamlineSimulation() in simulate_mice
  • it did produce a json output G4BLoutput.txt, but when I re-run simulate_mice with 
     bin/simulate_mice.py --input_json_file_name=G4BLoutput.txt --simulation_geometry_filename $MAUS_ROOT_DIR/files/geometry/download/ParentGeometryFile.dat
    I get an error:
    Traceback (most recent call last):
  File "/home/durga/develG4beamline/src/common_py/ErrorHandler.py", line 162, in HandleCppException
    raise CppError(error_message)
ErrorHandler.CppError: Property mc_events  not found in Json object lookup at JsonWrapper::GetPropertyStrict
...

Attached G4BLoutput.txt

Note: when I ran with the txt input, I turned off MapPyBeamlineSimulation().
What am I missing? Do I need modify anything else?

#10

Updated by Nugent, John over 9 years ago

Hi Durga,

1. I have cleaned up the G4BL output, the other files aren't really necessary so I just removed them from the G4BL output.

2. I believe this is missing the InputPyJSON inputter. This should be included in the simulate_mice.py when running with this JSON as an input. However when I ran this I noticed that although it did not return an error if failed to populate the MAUS primaries. I believe this is related to the error above. I have now resolved this issue by writing the G4BLoutput.txt after it has been processed by MapPyBeamMaker.py rather than after CallG4bl.py. BeamMaker appends the correct labels mc_events, maus_event_type etc and when used as input it runs without complaint.

I have uploaded the changes to my branch.

Cheers,
John

#11

Updated by Rajaram, Durga over 9 years ago

I am getting a different error now with CallG4bl
----
Event 1999 Completed 2000 events realTime=2 sec 1000.0 ev/sec
Event 2999 Completed 3000 events realTime=2 sec 1500.0 ev/sec
Run complete 3297 Events 2 seconds
NTuple Z15050 71 entries

Exceptions: 0 Fatal, 0 Events Aborted, 0 Stuck Tracks (stopped), 14 Warnings
14 times: No rename
g4beamline: simulation complete -- exiting
Missing an end_of_run spill...
...creating one to flush the mergers!
TRANSFORM: Shutting down transformer
MERGE: Shutting down merger
INPUT: Shutting down inputer
OUTPUT: Shutting down outputer
Clearing Globals
Traceback (most recent call last):
File "bin/simulate_mice.py", line 60, in <module>
run()
File "bin/simulate_mice.py", line 57, in run
MAUS.Go(my_input, my_map, MAUS.ReducePyDoNothing(), my_output, datacards)
File "/home/durga/develG4beamline/src/common_py/Go.py", line 131, in init
self.get_job_footer())
File "/home/durga/develG4beamline/src/common_py/framework/single_thread.py", line 95, in execute
self.process_event(event)
File "/home/durga/develG4beamline/src/common_py/framework/single_thread.py", line 139, in process_event
event = self.transformer.process(event)
File "/home/durga/develG4beamline/build/MapPyGroup.py", line 166, in process
nu_spill = worker.process(nu_spill)
File "/home/durga/develG4beamline/build/MapPyBeamlineSimulation.py", line 268, in process
self.random_seed)
File "/home/durga/develG4beamline/build/CallG4bl.py", line 240, in init
raise IOError(err)
IOError: [Errno 2] No such file or directory: '/home/durga/develG4beamline/maus_beam_output.txt'
-----

  • running with r721
    [durga@fermice1 develG4beamline]$ bzr revno
    721
    [durga@fermice1 develG4beamline]$
  • log of diff against your branch attached [ only change I made was to uncomment the g4bl stuff in ConfigurationDefaults ]
#12

Updated by Nugent, John over 9 years ago

Sorry Durga, I updated all of the files names in /build/CallG4BL.py. Have now copied the change in file names to /src/map/MapPyBeamline/CallG4BL.py. If you grab the changes from my branch now it should work.

#13

Updated by Rajaram, Durga over 9 years ago

Thanks, John. That fixed it.
But the G4BLoutput.txt file does not contain any events -- see attached, also attached log from running simulate_mice.py

#14

Updated by Nugent, John over 9 years ago

I think what is happening is that you are creating a hundred spills all called G4BLoutput.txt and the last one is empty so the output is empty. Normally I am interested in writing a single output beam file as you only need one input. Try it with spill_generator_number_of_spills set to 1 and it should work. If you want to populate multiple spills is a single go you would need to set the variable particles_per_spill in the g4bl dictionary to some number other than zero (zero take every particle in the buffer in the current spill). Also proton_number would have be increased such that a sufficient number of particles are simulated in g4bl to populate every MAUS spill.

#15

Updated by Rajaram, Durga over 9 years ago

Hi John -- ok I see It did work after I set the number of spills to 1.

I am willing to get this into the trunk -- there are a few things that I'd like to see happen before - or at least soon after a first version gets in.

  • Is it possible to have an option to write out the beam particles to a flat file in g4bl format? [ e.g. src/map/MapPyBeamMaker/test_g4bl.dat ]
    I think if you have that option, then we can enable a file-input datacard and have beammaker read it, and have the generation+simulation streamlined in one go?
  • If you want to write out json, I do think we want the ability to separate out multiple spills -- how difficult do you think it will be to distribute the events amongst different spills? Note that InputPySpillGenerator already generates N empty spills, where N=spill_generator_number_of_spills. So, I think all that has to be done is to distribute n_g4bl_events into N spills?
  • can you add documentation and user-instructions to the wiki/tex?
#16

Updated by Nugent, John over 9 years ago

Hi Durga,

yes it is possible to write the output as a raw bltrackfile from g4bl, this is already done in the background with this mapper. The reason for the conversion to JSON is that when moving from G4BL to MAUS the beam must be rotated so that it oriented correctly with respect to the MAUS geometry. This done by reading in the bltrackfile writing the elements to a python dictionary and multiplying by the rotation matrix. The output python dictionary is written to file and a python dictionary is essentially a JSON document, it just requires the labels which MapPyBeamMaker.py gives it. Giving the raw input file would mean do another conversion back to a track file which would just make things more complicated and the JSON document has already been created anyway.

Yes it shouldn't be too difficult to distribute the events between spills. Just set particles_per_spill to the number you would like for each spill and make proton_number a very large number (10^13) and it will populate each spill with the requested number of particles.

I will try and get the documentation on by the end of this week or the start of next.

#17

Updated by Nugent, John over 9 years ago

Hi Durga,

just to follow up on the discussion at the MAUS meeting yesterday. If you have the mapper MapPyBeamline.py in simulate_mice.py and the dictionary set the in the datacard then is will produce a json document called particles. This is appended to mc_events in the empty spill emitted by the inputter. There are no extra variables which have to be set and you do not have to run Beamline twice, once to create a file and the second time to read it in. In every case the json dump is picked up and appended to the spill document which BeamMaker handles in the usual manner. To see this you can put a print statement after BeamMaker has done its work and print out the spill document and you will see that it contains the particles created by G4BL.

Also available in: Atom PDF