Re: named models

David P. Huenemoerder wrote:
> I also wrote a multi-gauss function for someone else
Actually no -- that was me, too! ;-)

> once
Or more precisely: a few minutes before 03/27/2007, 16:09:44 -- this is
the date of the printout you gave me, which I happen to still have. :-)

> one name ("ngauss"), but more parameters (like "ngauss(1).center_23")
That was also back in the time when ISIS (<1.4.6) did not give a warning 
when the model string was too long.

> The risk is that you have to run the script which defines the model 
> (name and parameters) before loading any par file.
At my institute, our collection of ISIS scripts is always available to 
any user (it is updated automatically from the git repository, and its 
location is added to the global load path of the ISIS installation).
Virtually every analysis script starts anyway with
    require("isisscripts");
such that these model definitions are enabled almost at the beginning. 
(By the way, the same situation arises when local models are used. 
Before calling load_xspec_local_models, load_par obviously can't work.)

If organized well, every user can also keep its own library -- a single
call to add_to_isis_load_path in the ~/.isisrc should be sufficient.
(I've also heard of users putting *all* their own functions immediately 
in their ~/.isisrc...) I agree that some "thinking ahead" is required, 
if one wants to stay backward compatible (especially with oneself, as 
you correctly point out), but I believe that this shouldn't stop one 
from collecting functions in a library. For me, quite the contrary, it's 
usually good when I'm forced to really think about my functions... ;-)

Cheers,

Manfred


> (I don't think it is possible in general to know what model function
> should be assigned to any name from the par file itself, but maybe
> John has included some support for that).  So you do need to think
> ahead if you want to have easily reusable par files -- you need to
> write your model-definition script carefully and load it before using
> your models.  If sharing models via a par file, you also have to
> share code (and remember, you usually have to share with your future
> self, when trying to re-run something from a year or two ago and your
> code changed, but par files didn't).
> 
> I typically work with ~100 lines, and am happy to have them named 
> gauss(n).  Usually n < 8, since I fit one "feature" (region of the 
> spectrum with interesting lines and their nuisance blends) at a time.
> 
> 
> My solution for naming models was to write a manager which contains 
> the info about every region and which uses a database of line 
> mnemonics ("Ne9HeLar", "Fe19w13.42", etc) which can be used to 
> evaluate other properties (e.g., the plasma database ids, the 
> emissivity vs T).  So I do work with the mnemonics rather than
> knowing which n in gauss(n) is what.
> 
> Fitting is idiosyncratic, but ISIS supports that by letting you
> define and manage your own procedures, appropriate to your data and
> habits (good and bad).  In my case, 1) named models didn't exist when
> I wrote the scripts, and 2) there was extra information I wanted to
> handle. Regarding 1 - today I still would not use the names for the
> models, but that's my preference.
> 
> -- Dave
----
You received this message because you are
subscribed to the isis-users list.
To unsubscribe, send a message to
isis-users-request_at_email.domain.hiddenwith the first line of the message as:
unsubscribe