Ensure consistency between configurations on different systems

Create issue
Issue #52 new
anonymous created an issue

This can be done e.g. by distributing thorn lists automatically (similar to source code and parameter files), and by deriving a configuration name from the thorn lists automatically. In this way, configurations on different systems would (almost automatically) be based on the same thorn list.

Keyword:

Comments (4)

  1. Frank Löffler
    • removed comment

    I don't think this is a good idea. In part, because it goes against my usual practice. I usually call configurations simply 'sim' out of convenience and often have several complete checkouts for different configurations - often because I do have different versions of the same thorn, or would like to update some thorns for one configuration but not another. I would not be interested in a simulation name similar to the thornlist name. Just for the record: yes, I do usually use the same thornlist for the same checkout and configuration name. I just don't see the need to enforce that.

    This ticket is already quite old. If there is no other opinion within a week or so, I will probably close it - because it is also not known who actually submitted it.

  2. Erik Schnetter
    • removed comment

    One of Simfactory's goals is to remove the difference between different machines. Ideally, one would just "submit" a simulation, and some semi-automated mechanism would figure out where to submit (or would submit multiple times and keep only the first job that then starts), or would allow easily to restart on a different system, allows monitoring all current simulations independent of where they are running, etc.

    I have two thorn lists (development and production) in two different source trees, and use the same thorn lists on all systems. If a thorn doesn't work on a particular system this is noted in the MDB. I almost never specify a configuration name manually. If the default changed from "sim" to the thorn list name, I would not be bothered much.

    In a way, this ticket is already implemented. Simfactory distributes e.g. the manifest directory, and one can set a default thorn list in defs.local.ini.

    Are there people who regularly build multiple configurations in the same source tree?

  3. Ian Hinder
    • removed comment

    At the moment I have configurations for both Damiana and Datura in the same source tree, but--as suggested I think by Erik--this would be better handled by having different source tree locations for the different machines (they share a head node and home filesystem).

    Most of the time I just use the default configuration name of "sim". I would like this to use the default thornlist I have configured in defs.local.ini, which used to work but I believe is now broken (I should create a ticket for this). However, I also use other configurations. For example I might have a small configuration for testing simfactory, another for testing Kranc examples, maybe one for Carpet-Git and another for Carpet-HG (I put the different Carpets in different arrangements in the same source tree). So yes, I have multiple configurations.

    I think a mapping between thornlists and configurations makes sense, in the same way as I virtually always have a mapping between parameter files and simulations. The only problem with this is that thornlist names tend to be long and the configuration name would have to be typed for every simfactory command. This could be solved by supporting [http://www.debian-administration.org/articles/316 bash-completion] in simfactory so that you could tab-complete on the configuration name. One could also use short names for thornlists instead of long names.

    So, I support the original suggestion and think it is a good idea. It would be useful in the case where I have an old configuration and can't remember what thornlist I used for it.

  4. Bruno Mundim
    • removed comment

    Answering Erik: yes, I do regularly build multiple configurations in the same source tree, specially due to the large memory footprint of a ET checkout. So I don't like to have more than two (development and release) Cactus trees. I wouldn't mind to map thornlist name to configuration names (as long as tab completion is implemented too, as Ian suggested), but I don't see the point on enforcing it. The user should be able to set a different configuration name based on the same thornlist name with some thorns swapped by their private counterparts, for example, like Frank described.

  5. Log in to comment