Re: [Users] use of NO_ALLOCATION in simfactory machine definition files
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 -- 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. pgprOo7XKWiPv.pgp Description: OpenPGP digital signature ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] use of NO_ALLOCATION in simfactory machine definition files
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 signature.asc Description: Digital signature ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] use of NO_ALLOCATION in simfactory machine definition files
On Sun, Sep 18, 2016 at 11:51:08AM -0500, Roland Haas wrote: I would like to remove the allocation = NO_ALLOCATION lines from simfactory's machine definition files. I think this is fine, as long as simfactory aborts if none was set. This would a nice improvement. Frank signature.asc Description: Digital signature ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Re: [Users] use of NO_ALLOCATION in simfactory machine definition files
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 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 > > -- Erik Schnetter http://www.perimeterinstitute.ca/personal/eschnetter/ ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
[Users] use of NO_ALLOCATION in simfactory machine definition files
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. pgp6oGKmCfHMC.pgp Description: OpenPGP digital signature ___ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
