You have found some more ancient relax legacies. There is a lot of
perfectly functional legacy code in there! These counters should
probably not be placed into 'self'. They are re-initialised to zero
at the start of each iteration of the main model-free minimise() loop.
The only place these are now accessed from is the minimise()
function. The placement into 'self' is not always for storing state,
it has been used so that other functions can access the data without
having to pass arguments between the instance methods (which
technically is state anyway :). Yet in this situation this is no
longer the case.
The model_free instance is not singleton. There is a single instance
located at 'self.relax.specific.model_free' which all of relax
accesses. But the class can be reinitialised as many times as you
like, although there probably isn't much use for this (then again I
can't foresee what others will do with the module).
Cheers,
Edward
On 3/29/07, gary thompson <garyt.and.sarahb@xxxxxxxxx> wrote:
Another question about parallelising model_free minimise
model_free.py carrys around a grab bag of state and some of what might
be called pseudo state for the object (some of the state is only
relevant within one function call and effectively is a hidden local
variable and method/function argument e.g param_vector and
self.disassemble_param_vector). Now specific_fns.model_free.minimise
has the following code after the minimise and self.f_count etc are
clearly state
self.f_count = self.f_count + fc
self.g_count = self.g_count + gc
self.h_count = self.h_count + hc
who and what is this state save for and where is it accessed? because
i might well not have the same minimise instance when I get back from
multiprocessing to save it to (or is there only one instance of
model_free? is it a singleton? it certainly looks so from my tests
and in actual fact effectively this data is module level data in
specific_functions.model_free am I correct ;-)
Re: how to parallelise model_free minimise