Hello all,
I would like to remove the
allocation = NO_ALLOCATION
lines from simfactory's machine definition files.
They seem to have not benefit that I can see and cause two types of problems:
* simfactory does not default to the allocation in the [default] section which is the only one set up when doing sim setup on the cluster itself
* simfactory does not warn/abort if no allocation is set for the cluster since as far as simfactory is concerned, there actually is an allocation defined (namely "NO_ALLOCATION"). This is eventually caught by qsub and friends but simfactory's handling of qsub errors is not very good unfortunately
Does anyone remember why we introduced NO_ALLOCATION? And would anyone object to remove it from all the affected ini files (which is most of them it seems).
Yours, Roland
Roland
NO_ALLOCATION was introduced for backward compatibility. Initially, most Simfactory users used the same allocation (LSU numrel group), and we entered this into the MDB. Later this was not a good default any more, so we replaced it with something "neutral".
This looks like a good idea. We might need to update the MDB definition as well to make this key either required or optional (don't know which is better).
-erik
On Sun, Sep 18, 2016 at 12:51 PM, Roland Haas rhaas@illinois.edu wrote:
Hello all,
I would like to remove the
allocation = NO_ALLOCATION
lines from simfactory's machine definition files.
They seem to have not benefit that I can see and cause two types of problems:
simfactory does not default to the allocation in the [default] section which is the only one set up when doing sim setup on the cluster itself
simfactory does not warn/abort if no allocation is set for the cluster since as far as simfactory is concerned, there actually is an allocation defined (namely "NO_ALLOCATION"). This is eventually caught by qsub and friends but simfactory's handling of qsub errors is not very good unfortunately
Does anyone remember why we introduced NO_ALLOCATION? And would anyone object to remove it from all the affected ini files (which is most of them it seems).
Yours, Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On Sun, Sep 18, 2016 at 12:58:27PM -0400, Erik Schnetter wrote:
This looks like a good idea. We might need to update the MDB definition as well to make this key either required or optional (don't know which is better).
That is a good thought. Not every machine requires an allocation name. If we would make it a required field, it would force users to choose something even for machine that don't need it. On the other hand, we could work around that by providing 'something' (notneeded?) for those machines, and not use the string in the qsub script. Although, that does sound a little 'hacky'.
I would suspect that making it optional begs the question what simfactory should use to replace the potentially present strings in the qsub file with, and why it should warn or abort if none was given.
Frank
Hello all,
That is a good thought. Not every machine requires an allocation name. If we would make it a required field, it would force users to choose something even for machine that don't need it. On the other hand, we could work around that by providing 'something' (notneeded?) for those machines, and not use the string in the qsub script. Although, that does sound a little 'hacky'.
I would suspect that making it optional begs the question what simfactory should use to replace the potentially present strings in the qsub file with, and why it should warn or abort if none was given.
Making it optional or required does not make much of a difference given that right now sim setup puts an "allocation" entry into the [default] section so that if the machine does not define an allocation the [default] one would be used.
Note that currently simfactory requires that all required entries are set (either in the [XXX] section for the machine or in [default]) even for machines that are not used. ie. if allocation is required then the user is pretty much forced to have one in [default] since otherwise simfactory will abort (for all commands!) due to some exotic machine to which the user has no access not having its allocation setting set.
Yours, Roland
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Frank Loeffler -
Roland Haas