Open cherylepatrick opened 5 years ago
For reference, here are CCLyon's docs on Singularity and Batch:
Hi Cheryl,
I'm not totally convince about singularity stuff at CC for the superNEMO analysis training. If peoples want to use Falaise@CCLyon, up to now, an expert propose cadfael+bayeux installation and they have only to install their own Falaise (if needed, an official version exist).
We should concentrate our effort (only half a day for that training) about :
What's your feeling ?
Just for the record, on September 21, 2018, I have asked explicitly to establish a central install of the SuperNEMO software at Lyon. There is only one SuperNEMO software. No such thing as an 'expert install' can exist by definition. I asked the software coordinator last year to investigate alternative methods to enable the collaboration to work with a uniquely defined software. The container solution fits that description and is supported by Lyon. It is therefore one of the potential solutions for the collaboration to work consistently with SuperNEMO data at Lyon and anywhere else. Other solutions exist and are being pursued. Collaborators may choose which software deployment works best for them as long as it is the one SuperNEMO software. Learning about the various and growing number of consistent deployment methods is therefore recommended.
@cherylepatrick, @lemiere, the stopgap Homebrew is in place, with updated images. The main docs for Singularity with Lyon specifics are now here:
https://github.com/SuperNEMO-DBD/brew#installing-images
and
https://github.com/SuperNEMO-DBD/brew#using-the-supernemo-software-environment
I've tested these at CC-Lyon and worksforme in these very basic use cases. I haven't tested batch yet, that's next. Additional comments/feedback welcome.
@yramachers, you can also try out the above at Warwick!
Thanks @drbenmorgan and sorry to be the bearer of bad news as usual, but it isn't working for me on CCLyon. Looks like the error is [void mctools::g4::detector_construction::write_tmp_gdml_file():1313: Cannot create GDML temporary file !]
. Attaching log file in case it helps.
test.01.flsimulate.txt
Any idea if I am doing something daft?
Thanks @cherylepatrick, not daft at all, I think you've found a bug/oddity in using the Docker image as I prepared it in Singularity. The image sets the USER
environment variable to snemo
which is correct for Docker, but not for Singularity. It's the USER
variable that flsimulate uses to create tmp directories (/tmp/snemo/...
) and I'd bet you were clashing with my run from earlier!
I don't have an immediate fix for the image (though I think I know how to), but to see if the above is the case, try:
$ singularity shell --home $HOME falaise.simg
Singularity: Invoking an interactive shell within container...
Singularity falaise.simg:~> export USER=`whoami`
Singularity falaise.simg:~> brew test falaise
That should work...
It does! Thanks @drbenmorgan !
O.k., this should now be fixed in the main Docker image. I've tested at CC IN2P3 and it looks to work, and I've also confirmed that the basic instructions on their Singularity and Grid Engine page allow submission and successful run of a trivial job script:
#!/bin/bash
singularity run --home $HOME --bind /sps $HOME/falaise-latest.simg flsimulate -o $HOME/first-job.brio
More complex workflows need testing, as well as overall performance, but the basics are there. I've also updated the README with some of this info.
If that looks o.k., I'll use as the basis for the tutorial instructions.
We have most of this available already, I think, but we need to do a bit more testing with singularity/batch.