damiana setup in simfactory is wrong

Comments (8)

1. 

   Erik Schnetter

   • removed comment

   The reason for this is likely that Damiana and Datura share the same home directory, but require different configurations. Therefore, respective source trees are stored in subdirectories of the home directory.

   • 2011-10-13T08:52:24+00:00
2. 

   Ian Hinder

   • changed status to resolved
   • removed comment

   This was an intentional change, not an error. Erik is correct as to the motivation. Luca, if you want to request that the default be changed, please open an enhancement ticket saying why you think it is better to have a common source and build directory for the two machines rather than having them separated (it's not 100% clear to me which is better, but I currently lean in the direction of keeping them separate).

   • 2011-10-13T21:41:35+00:00
3. 

   Frank Löffler

   • removed comment

   There are reasons to do both. On one hand, it should not be necessary to have two separate source trees. Separate configurations should be sufficient to handle two different machines using the same source tree. Are they not? On the other hand, an argument against it is that you might accidentally use the wrong configuration for a given machine - but then you could name the configurations after the machines. This of course does not have the convenience of a default configuration name 'sim', which does not need to be specified explicitly. On the other hand - one source tree means no syncing, no source differences, no additional space used ect.

   • 2011-10-13T21:54:01+00:00
4. 

   Ian Hinder

   • removed comment

   The other argument in favour of having a single source tree is that it is weird if you are using datura (for example) as your "central" source location. You would end up syncing the tree to the damiana directory on the same machine, and I'm not even sure if this works. Perhaps the ideal solution would be to have different configuration and exe directories for each machine. So you would have a single Cactus directory with Cactus/damiana/exe, Cactus/damiana/configs, Cactus/datura/exe, Cactus/datura/configs. Cactus can be told to use a different configs (and exe?) directory with an environment variable.

   This doesn't solve the problem of having to specify which machine you want to use when running every simfactory command. In my case, I would be satisfied by having a default. Currently simfactory refuses to run unless you tell it which machine. I would like to select datura as the default in that case, as I rarely use damiana. SimFactory should also carefully check that you don't use a damiana configuration on datura and vice-versa (for building and submitting etc).

   • 2011-10-14T09:04:54+00:00
5. 

   Barry Wardell

   • removed comment

   Replying to [comment:4 hinder]:

   The other argument in favour of having a single source tree is that it is weird if you are using datura (for example) as your "central" source location. You would end up syncing the tree to the damiana directory on the same machine, and I'm not even sure if this works. Perhaps the ideal solution would be to have different configuration and exe directories for each machine. So you would have a single Cactus directory with Cactus/damiana/exe, Cactus/damiana/configs, Cactus/datura/exe, Cactus/datura/configs. Cactus can be told to use a different configs (and exe?) directory with an environment variable.

   I think I remember discussing this before at some stage. The suggestion I liked best (and the one I currently use) is to have a single source tree and to have separate configurations named after the machine. If SimFactory was to use the machine name as the configuration name instead of 'sim' (I think this was also proposed at some stage), then this would be an ideal setup as it should 'just work' without needing to specify the configuration each time.

   This doesn't solve the problem of having to specify which machine you want to use when running every simfactory command. In my case, I would be satisfied by having a default. Currently simfactory refuses to run unless you tell it which machine. I would like to select datura as the default in that case, as I rarely use damiana. SimFactory should also carefully check that you don't use a damiana configuration on datura and vice-versa (for building and submitting etc).

   I agree that this would be a nice feature to have, although it is somewhat of a separate issue to the one Luca is reporting.

   • 2011-10-14T10:24:44+00:00
6. 

   Erik Schnetter

   • removed comment

   Most of the space is used by the configurations. I estimate that a configuration uses about three to four times as much space as a source tree, if you exclude test results.

   Simfactory already ensures that a configuration is not used in the wrong way. Once you created a configuration, you can rebuild, submit, etc., and it will automatically remain self-consistent and will always submit to the same machine. You can manually (and possibly accidentally) change parts of the configuration, but that is not different from what you can to in any other situation. If you re-configure, Simfactory will notice this, and will enforce rebuilding everything from scratch.

   We can make Datura the default. You may even be able to do that by yourself with the command

   echo datura > /.hostname

   The underlying problem is that there are two separate machines sharing the same head node. Damiana/Datura are unique in this respect. Can this be changed? Can there be a second head node? Isn't there a second head node anyway that could be used? Don't you have that problem for every executable, having to remember for which machine you built it?

   • 2011-10-14T10:57:50+00:00
7. 

   Barry Wardell

   • removed comment

   Replying to [comment:6 eschnett]:

   The underlying problem is that there are two separate machines sharing the same head node. Damiana/Datura are unique in this respect. Can this be changed? Can there be a second head node? Isn't there a second head node anyway that could be used? Don't you have that problem for every executable, having to remember for which machine you built it?

   We asked Nico about a second head node in the past, but he was keen to keep a single unified environment as much as possible. Note that it is possible to use the same executable on both machines. The only difference between their OptionLists is the SSE version used (2 on Damiana and 4 on Datura) so an executable built for Damiana runs fine on Datura. We even have a single environment for both machines. What is not the same is the machine entry - they have different queues, ppn, etc. These are things which only affect SimFactory.

   • 2011-10-14T11:06:49+00:00
8. 

   Roland Haas

   • edited description
   • changed status to closed

   • 2019-02-21T20:23:26+00:00
9. Log in to comment