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


-- 
Erik Schnetter <schnet...@cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/
_______________________________________________
Users mailing list
Users@einsteintoolkit.org
http://lists.einsteintoolkit.org/mailman/listinfo/users

Reply via email to