Modify

Opened 8 years ago

Last modified 7 years ago

#52 new enhancement

Ensure consistency between configurations on different systems

Reported by: anonymous Owned by: mthomas
Priority: minor Milestone:
Component: SimFactory Version:
Keywords: Cc:

Description

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.

Attachments (0)

Change History (4)

comment:1 Changed 7 years ago by Frank Löffler

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.

comment:2 Changed 7 years ago by Erik Schnetter

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?

comment:3 Changed 7 years ago by Ian Hinder

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 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.

comment:4 Changed 7 years ago by bmundim

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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain mthomas.
Next status will be 'review'.
as The resolution will be set.
to The owner will be changed from mthomas to the specified user.
Next status will be 'confirmed'.
The owner will be changed from mthomas to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.