Simfactory: add --basedir=@BASEDIR@ to all submit scripts

Issue #1672 resolved
Bruno Mundim created an issue

I would like to add the option, --basedir=@BASEDIR@, choosing the simulation directory to all simfactory submit scripts at ./mdb/submitscripts. I hope they become more homogeneous with respect to features simfactory already supports.

Keyword: Simfactory
Keyword:
Keyword: basedir

Comments (12)

  1. Bruno Mundim reporter
    • removed comment

    Not having to add that option machine by machine after I submit a job and be reminded that that option is not there for that particular machine I used. So why not change to all machines once and for all while it is still fresh in my memory?

  2. Roland Haas
    • removed comment

    I am not sure I understand exactly what the new option would do. I am not quite sure what you mean by

    --basedir=@BASEDIR@
    

    ie do you use @BASEDIR@ as just a placeholder in your ticket or do you want it to be simfactory's placeholder @BASEDIR@?

    You can have something like:

    [default]
    basedir = /home/bmundim
    
    [foo]
    basedir = /work/bmundim
    
    [bar]
    basedir = /home1/bmumdim
    

    in you simfactory simfactory/etc/defs.local.ini which will use /home/bmundim as the basedir on all machines that do not specify anything in their machine.ini and /work/bmundim for machine foo (overriding what may be in its machine.ini) aand /home1/bmumdim for the machine bar.

    Is that what you'd like to achieve?

  3. Bruno Mundim reporter
    • removed comment

    do you use @BASEDIR@ as just a placeholder in your ticket or do you want it to be simfactory's placeholder @BASEDIR@?

    I used as a simfactory's placeholder.

    Is that what you'd like to achieve?

    No. What I want to achieve is the ability to choose where to send my simulation. For example, I could split my several simulation directories according to their common purpose:

    sim create-submit blah --machine superblah --basedir /path/to/BBH/simulations

    or

    sim create-submit blah --machine superblah --basedir /path/to/scaling/simulations

    or

    sim create-submit blah --machine superblah --basedir /path/to/GRMHD/simulations

    etc...

    It just allows me to organize my tons of simulations in directories different from the one in the machine definition or simfactory/etc/defs.local.ini

  4. Ian Hinder
    • removed comment

    Yes, this is a useful feature. I believe you are saying it is already supported by SimFactory, but it requires implementation in the machine-specific scripts, and this is not done consistently. Is that correct?

    This is one major problem with SimFactory2 - a lot of logic needs to be duplicated in each run script.

    I currently have a separate defs.local.ini for each Cactus tree, which roughly corresponds to a project, and in that I set basedir. Being able to customise this on a per-machine basis might be useful, though I have not yet needed that feature.

  5. Bruno Mundim reporter
    • removed comment

    Yes, this is a useful feature. I believe you are saying it is already supported by SimFactory, but it requires implementation in the machine-specific scripts, and this is not done consistently. Is that correct?

    Yes, that's correct. It is a matter of updating all machine submit scripts.

  6. Roland Haas
    • removed comment

    Since this is agreed upon to be a useful feature, would you be able to provide a patch for review, please? Also if you were to test (on at least one machine) that this actually works as expected (likely since supermuc and loewe already use it), ie. that simfactory recognizes the option when the option is passed to the "run" command, that would be great.

  7. Bruno Mundim reporter
    • removed comment

    I have attached a patch. Unfortunately I don't have access to all machines. I will test on other machines that I have access and report back later. Please test it on your machine too.

  8. Ian Hinder
    • changed status to open
    • removed comment

    I think the concept of this simple patch is obviously correct, because this is already in use on some machines. The only potential problem would be a typo in the patch. I have looked at the patch carefully, and do not see any typos. I believe it should just be applied, with no need to require testing on all machines.

  9. Log in to comment