fit -r <n> uses fitted parameter values as initial values for the next fit

[nsjarvis]

I have a SDME-style fit with only a few amplitudes and then many parameters. I find that fit -r reuses the final parameter values from one fit as the initial values for the next, unless I use parRange for each parameter. If I use parRange, then both the amplitudes and parameter values get random start values each time, and this -r is super-convenient.

If this behaviour is intentional then it just needs to be documented. If not, then I already found a workaround (use parRange). If it's caused by a bug in my config file then please tell me where to find it. :-)

I put example files into /cache/halld/home/njarvis/examples/randomizedfits and /cache/halld/home/njarvis/examples/repeatonifarm . In each case the fit output is in fit_output.txt

[mashephe]

This behavior matches what is coded. // randomize parameters ati.randomizeProductionPars(maxFraction); for(size_t ipar=0; ipar<parRangeKeywords.size(); ipar++) { ati.randomizeParameter(parRangeKeywords[ipar][0], atof(parRangeKeywords[ipar][1].c_str()), atof(parRangeKeywords[ipar][2].c_str())); } If you don't specify a range over which to randomize the parameter, then nothing can be done. Unlike production parameters that scale amplitudes, there is no natural scale for an arbitrary parameter. Matt

…

On Mar 27, 2023, at 8:41 AM, nsjarvis ***@***.***> wrote: I have a SDME-style fit with only a few amplitudes and then many parameters. I find that fit -r reuses the final parameter values from one fit as the initial values for the next, unless I use parRange for each parameter. If I use parRange, then both the amplitudes and parameter values get random start values each time, and this -r is super-convenient. If this behaviour is intentional then it just needs to be documented. If not, then I already found a workaround (use parRange). If it's caused by a bug in my config file then please tell me where to find it. :-) I put example files into /cache/halld/home/njarvis/examples/randomizedfits and /cache/halld/home/njarvis/examples/repeatonifarm . In each case the fit output is in fit_output.txt — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[nsjarvis]

It is the reuse of the previous fit results that I found surprising.

[jrstevenjlab]

After discussion at the software meeting yesterday, I think I understood Naomi's remaining request is to (by default) reset the non-production parameters to the values initialized in the input fit configuration file. This way the production parameters can be randomized while some other amplitude parameters are always started from some specified point from the fit configuration file (rather than being copied over as the same value as the previous iteration of the randomized starting values).

That said, for the SDME fits the parRange option is desired to vary the starting parameters of the SDME values each time the fit is restarted. Also, for the SDMEs it's undesirable to randomize the production parameters since there is only really one amplitude being used in the intensity (despite constructing different sums for each polarization orientation). So, it would be preferred to also have an option to randomize the amplitude parameters with parRange but without randomizing the production parameters. I'll look at this and make a proposal based on Naomi's example files.

[mashephe]

What is the use case for these fits? SDME fits do not suffer from general ambiguity problems present in many partial wave fits. While it is useful to look for alternate minima, it would be surprising if this were a consistent problem such that it required every single fit in the analysis to be consistently repeated hundreds of times with random parameters. When we agree that a solution needs to be implemented in software, let's discuss the desired solution. It may be good to implement in this in the AmpToolsInterface so that the desired changes are readily available. It also prevents the fit.cc code from getting too bloated. Matt

…

On Mar 28, 2023, at 7:37 AM, Justin Stevens ***@***.***> wrote: After discussion at the software meeting yesterday, I think I understood Naomi's remaining request is to (by default) reset the non-production parameters to the values initialized in the input fit configuration file. This way the production parameters can be randomized while some other amplitude parameters are always started from some specified point from the fit configuration file (rather than being copied over as the same value as the previous iteration of the randomized starting values). That said, for the SDME fits the parRange option is desired to vary the starting parameters of the SDME values each time the fit is restarted. Also, for the SDMEs it's undesirable to randomize the production parameters since there is only really one amplitude being used in the intensity (despite constructing different sums for each polarization orientation). So, it would be preferred to also have an option to randomize the amplitude parameters with parRange but without randomizing the production parameters. I'll look at this and make a proposal based on Naomi's example files. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.

[nsjarvis]

Thank you Justin for writing my requests more clearly.

1. I found it so surprising that the default behaviour for randomized fits is to reuse the previous fit results as a starting point for the next fit that I thought that it might be a bug. I understand that to randomize the parameter start values, parRange should be supplied. Now that I'm aware of parRange I can mostly do what I need to, but I would also like to save others from repeating my mistakes, while not making unnecessary work. I can see three options: (a) document this behaviour (b) have the code print a warning if fit -r is invoked when the parameters lack parRange (c) change the default behaviour so that the parameters without parRange have their initial values set for each fit. Maybe we could ask at the next AAWG meeting which would be preferred.

2. I am using fit -r for SDME fits even though they should be very simple, because in practice I find that many fits fail with a not pos-def error matrix, and repeating the fit attempts many times with slightly different starting parameters sometimes finds successful solutions. I think everyone doing SDME fits has run into this problem. The recent change to not produce the fit file if the fit did not converge properly has made the pos-def problems more noticeable (often the not pos-def fits looked ok).

[jrstevenjlab]

Following up on @nsjarvis 1.: the solution option (c) to reinitialize all the parameter values to those from the configuration file before randomizing is straightforward and I think the right approach to make sure there's not a history of a previous random seed in a future random starting point.

We already have a function AmpToolsInterface::reinitializePars() that we use for parameter scans to reset all the parameter values to those from the configuration file and then modify the parameter being scanned. So I would suggest we make this change to the default behavior by either:

• Calling AmpToolsInterface::reinitializePars() in the fit.cc and fitMPI.cc code before the parameters are randomized (same as what we do for parameter scans)
• Or add a call to reinitializePars() in AmpToolsInterface::randomizedProductionPars() before the randomization is done

@mashephe, what do you think of this proposal and implementation options to reset the non-production parameters for randomized fits?