Re: [Help-gsl] siman: fixed vs variable configurations

[John Gehman]

Thanks, Brian -- that was a bit silly of me -- I neglected to spot  
the detail in the travelling salesman problem that would have led me  
to that.

And I will be happy to be embarrassed again by an easy answer to that  
which has me stumped now that I'm a bit further down the track. I'm  
still learning how to control the behaviour of the solver and  
annealing, but ...

My gsl_siman_Efunc_t receives the void * argument which refers to my  
data struct, a component of which is the gsl_vector which holds the  
(17) values that I want to search for/optimize. The optimum values  
provide for the best fit to data, and it is the rmsd between the data  
and fit which I return as "Energy". I also set the "double rmsd"  
component of the data struct to this same value.

As the temperature cools, a params->iters_fixed_T number of different  
configurations are tried. The configuration corresponding to the  
minimum energy (rmsd) at each temperature is written to the original  
input struct. However the Ef(x) output associated with the  
gsl_siman_print_t function prints the minimum energy (rmsd) found  
thus far, at any temperature.

As if having hit a local minimum, after the temperature at which this  
minimum energy is found, the energy bounces back up again, but then  
never comes back down to this or any lower energy. But still the Ef 
(x) value persists to report the apparently globally minimum energy  
value. Oddly, a check of ((struct mysystem *) xp )->rmsd reports this  
same value.

When the minimum temperature is reached, mysystem contains the  
configuration of sought-values only for the minimal energy of the  
last temperature run, not the configuration corresponding to the  
globally minimum value, but the ((struct mysystem *) xp )->rmsd  
*does* reflect the globally minimum value, as above.

If I rerun the same function as referenced for the gsl_siman_Efunc_t,  
the latest values are used and the (struct mysystem *) xp )->rmsd  
value *does* change to a correctly corresponding elevated value.

I've been hammering at this for ages now, do you reckon I've done  
something stupid, or is there perhaps some mixup in the siman code  
that could explain this?

Regards,
john


On 25/04/2006, at 5:07 AM, Brian Gough wrote:

> The size parameter should then be sizeof(struct mysystem).