errors importing Artemis project with quick first shell paths
Ian, I am starting a new thread for your email. It is only peripherally related to the problem discussed in the other thread. The main problem was two mistakes in how a quick first shell path was brought back to life when importing the project file. I'll explain, although one of the problems is rather technical. Mistake #1 is related to the option for auto-generating variables. That flag was not turned off, so the auto-generated parameters got regenerated, over writing the ones you chose. Yikes! Mistake #2 involved an assumption about the order of entries in a hash data structure while bringing the QFS path back to life. That is extremely sloppy on my part because the order of hash entries is not predictable. This was leading to the intermittent aspects of the behavior.
Dear All,
Sorry for resurrecting this old thread but I've been experiencing a bug that produces very similar symptoms and that I guess may be related; but that won't be solved by Bruce's fix. Details are as follows:
Software: Demeter 0.9.18.2 and 0.9.20 x64 (possibly earlier releases too) on Windows 8.1 x64 (I've never observed this bug on Windows versions before 8, but I've been using Windows 8 as my main OS for a while now so that may be coincidental)
Steps to reproduce: I run a fitting project using quick first shell fits and save it. When I re-open the project around 80% of the time the problem occurs.
Symptoms: When I re-open the project around 80-90% of the time one or more of the following occurs:
- One of the quick shell paths completely loses all its information (including path information which isn't editable by the user, parameter info etc; see attached screenshot)
I believe that I have fixed this.
- Parameter info for one or more paths is reset to the default (i.e. if I've named a path delrauau it's renamed dr_ag_au_1)
Again, I believe that I have fixed this.
- In the GDS window starting values for parameters that have a non-zero starting value are set to their previously guessed value, rather than the starting value I set (ie. If I set ss as 0.003 and during the fit it is guessed to be 0.001 when I reopen the project the starting value will be set to 0.001) and "restrain" parameters are changed to "guess".
I have examined the history of your project. At no point is a fit saved with a restraint. The GDS windows is filled correctly according to the contents of your project file. Also, the initial guesses are all entered into the GDS window with the values I see in the history. Are you saying that you have made a restraint, saved the project, then had Artemis fail to remember that you had made a restraint?
- Phase correct fitting boxes are unticked (sometimes in an "impossible fashion" where the "plot with phase correction" option is set but no paths have the "use path for phase corrected plotting" option set)
I don't understand how that can be a problem. The default is not to plot with phase correction. I don't save the state of that button in the project file in any case. I need to do a bit more testing, hopefully I'll make a new trial release package for your to test before the end of the day. B
Attachments:
Noinfo.png - screenshot of Artemis when path info is lost Reset.png - screenshot of Artemis when parameter names are reset Dartemis.log - Artemis log file when opening a project that has this problem Artemis.fpj - Artemis project file that displays these symptoms.
Please let me know if you need further info/files.
Thanks,
Ian
Ps: OK, things got weird while preparing this bug report: The file in question stopped opening at all - Artemis loaded and went through loading fit x, x+1 etc., once it finished (not exactly sure what stage) it just closed. And then, after several attempts, started working again, as if by magic, before I'd saved a log file.... If I can figure out how to reproduce this I'll send more info...
-- Bruce Ravel ------------------------------------ bravel@bnl.gov National Institute of Standards and Technology Synchrotron Science Group at NSLS-II Building 535A Upton NY, 11973 Homepage: http://bruceravel.github.io/home/ Software: https://github.com/bruceravel Demeter: http://bruceravel.github.io/demeter/
Ian (and anyone else interested), Could you go to http://bruceravel.github.io/demeter/#windows and try out pre-release #2 for 0.9.21? I think I have addressed all the problems you were running into with QFS paths -- I can read, fit, save, and re-import the project file you sent me and it behaves sensibly. You'll let me know if you agree. I have done nothing to address your 3rd and 4th points because I am not clear what you think the problem is. I think the program is behaving correctly on those points, but perhaps I don't understand the issue. B PS: Make sure to use the links that say "<< 64 bit installer >>" or "<< 32 bit installer >>". The link buttons in the side bar point at the 0.9.20 installer. On 10/27/2014 10:10 AM, Bruce Ravel wrote:
Ian,
I am starting a new thread for your email. It is only peripherally related to the problem discussed in the other thread.
The main problem was two mistakes in how a quick first shell path was brought back to life when importing the project file. I'll explain, although one of the problems is rather technical.
Mistake #1 is related to the option for auto-generating variables. That flag was not turned off, so the auto-generated parameters got regenerated, over writing the ones you chose. Yikes!
Mistake #2 involved an assumption about the order of entries in a hash data structure while bringing the QFS path back to life. That is extremely sloppy on my part because the order of hash entries is not predictable. This was leading to the intermittent aspects of the behavior.
Dear All,
Sorry for resurrecting this old thread but I've been experiencing a bug that produces very similar symptoms and that I guess may be related; but that won't be solved by Bruce's fix. Details are as follows:
Software: Demeter 0.9.18.2 and 0.9.20 x64 (possibly earlier releases too) on Windows 8.1 x64 (I've never observed this bug on Windows versions before 8, but I've been using Windows 8 as my main OS for a while now so that may be coincidental)
Steps to reproduce: I run a fitting project using quick first shell fits and save it. When I re-open the project around 80% of the time the problem occurs.
Symptoms: When I re-open the project around 80-90% of the time one or more of the following occurs:
- One of the quick shell paths completely loses all its information (including path information which isn't editable by the user, parameter info etc; see attached screenshot)
I believe that I have fixed this.
- Parameter info for one or more paths is reset to the default (i.e. if I've named a path delrauau it's renamed dr_ag_au_1)
Again, I believe that I have fixed this.
- In the GDS window starting values for parameters that have a non-zero starting value are set to their previously guessed value, rather than the starting value I set (ie. If I set ss as 0.003 and during the fit it is guessed to be 0.001 when I reopen the project the starting value will be set to 0.001) and "restrain" parameters are changed to "guess".
I have examined the history of your project. At no point is a fit saved with a restraint. The GDS windows is filled correctly according to the contents of your project file. Also, the initial guesses are all entered into the GDS window with the values I see in the history.
Are you saying that you have made a restraint, saved the project, then had Artemis fail to remember that you had made a restraint?
- Phase correct fitting boxes are unticked (sometimes in an "impossible fashion" where the "plot with phase correction" option is set but no paths have the "use path for phase corrected plotting" option set)
I don't understand how that can be a problem. The default is not to plot with phase correction. I don't save the state of that button in the project file in any case.
I need to do a bit more testing, hopefully I'll make a new trial release package for your to test before the end of the day.
B
Attachments:
Noinfo.png - screenshot of Artemis when path info is lost Reset.png - screenshot of Artemis when parameter names are reset Dartemis.log - Artemis log file when opening a project that has this problem Artemis.fpj - Artemis project file that displays these symptoms.
Please let me know if you need further info/files.
Thanks,
Ian
Ps: OK, things got weird while preparing this bug report: The file in question stopped opening at all - Artemis loaded and went through loading fit x, x+1 etc., once it finished (not exactly sure what stage) it just closed. And then, after several attempts, started working again, as if by magic, before I'd saved a log file.... If I can figure out how to reproduce this I'll send more info...
-- Bruce Ravel ------------------------------------ bravel@bnl.gov National Institute of Standards and Technology Synchrotron Science Group at NSLS-II Building 535A Upton NY, 11973 Homepage: http://bruceravel.github.io/home/ Software: https://github.com/bruceravel Demeter: http://bruceravel.github.io/demeter/
Hi Bruce, Thanks for your reply. Only pre release version 1 is listed on your website, but it's easy to guess the URL for version 2 so I've been using that. It seems to solve several of the problems opening files which is great, but there's a hitch: I've not been able to reopen test projects I've created in it (it gets to "restoring fits" and then closes - project and logs attached, more details later in this email). #> - One of the quick shell paths completely loses all its information #> (including path information which isn't editable by the user, #> parameter info etc; see attached screenshot) # #I believe that I have fixed this. Yes, this seems to be fixed now - thanks. #> - Parameter info for one or more paths is reset to the default #> (i.e. if I've named a path delrauau it's renamed dr_ag_au_1) # #Again, I believe that I have fixed this. This also seems to be fixed, thanks. #> - In the GDS window starting values for parameters that have a #> non-zero starting value are set to their previously guessed value, #> rather than the starting value I set (ie. If I set ss as 0.003 and #> during the fit it is guessed to be 0.001 when I reopen the project #> the starting value will be set to 0.001) and "restrain" parameters #> are changed to "guess". # #I have examined the history of your project. At no point is a fit saved with a restraint. The GDS windows is filled correctly according to the contents of your #project file. Also, the initial guesses are all entered into the GDS window with the values I see in the history. # #Are you saying that you have made a restraint, saved the project, then had Artemis fail to remember that you had made a restraint? Sorry - this is (partly) my memory playing tricks on me: I never did use a restraint in this project! That said I do recall experiencing this (restraint amnesia, as you describe) in other projects - if I can find one of the project files I'll send it on! If I can't then I'll assume it's me that's got the amnesia... Regarding the initial guesses this is what I experience (I've managed to understand the symptoms a bit more specifically now): I set up the initial guess values in the GDS window and run the fit. When I've finished working I save the project and exit. When I reload the project the initial guesses for guess parameters with an initial guess of 0 are set to the final guess from the previous fit (see attached screenshot of GDS + history window to demonstrate(artemis gds init guess 0 bug.png)). #> - Phase correct fitting boxes are unticked (sometimes in an #> "impossible fashion" where the "plot with phase correction" option #> is set but no paths have the "use path for phase corrected plotting" #> option set) # # #I don't understand how that can be a problem. The default is not to plot with phase correction. I don't save the state of that button in the project file in any #case. OK, I was assuming that saving the state of that option was intended behaviour. Regarding the issue I mentioned at the start about reopening project files I made in 0.9.21 I've attached the following (project + logs from 0.9.21 and from similar issues I've experienced (very) intermittently in 0.9.20): Project file saved in 0.9.21 that I can't reopen - artemis testing.fpj Log file from trying to open it (0.9.21) - dartemis.log Project file saved in 0.9.20 that I can't reopen - dualedgefitting.fpj Log file from trying to open it (0.9.20) - dartemis_current.log Thanks for taking the time to look into all this. Ian ---- Ian Godfrey PhD Student, UCL/JAIST Programme Industrial Doctorate Centre in Molecular Modelling and Materials Science, Department of Chemistry, University College London and School of Materials Science, Japan Advanced Institute of Science and Technology i.godfrey@ucl.ac.uk i.godfrey@jaist.ac.jp -----Original Message----- From: ifeffit-bounces@millenia.cars.aps.anl.gov [mailto:ifeffit-bounces@millenia.cars.aps.anl.gov] On Behalf Of Bruce Ravel Sent: 27 October 2014 14:10 To: XAFS Analysis using Ifeffit Subject: [Ifeffit] errors importing Artemis project with quick first shell paths Ian, I am starting a new thread for your email. It is only peripherally related to the problem discussed in the other thread. The main problem was two mistakes in how a quick first shell path was brought back to life when importing the project file. I'll explain, although one of the problems is rather technical. Mistake #1 is related to the option for auto-generating variables. That flag was not turned off, so the auto-generated parameters got regenerated, over writing the ones you chose. Yikes! Mistake #2 involved an assumption about the order of entries in a hash data structure while bringing the QFS path back to life. That is extremely sloppy on my part because the order of hash entries is not predictable. This was leading to the intermittent aspects of the behavior.
Dear All,
Sorry for resurrecting this old thread but I've been experiencing a bug that produces very similar symptoms and that I guess may be related; but that won't be solved by Bruce's fix. Details are as follows:
Software: Demeter 0.9.18.2 and 0.9.20 x64 (possibly earlier releases too) on Windows 8.1 x64 (I've never observed this bug on Windows versions before 8, but I've been using Windows 8 as my main OS for a while now so that may be coincidental)
Steps to reproduce: I run a fitting project using quick first shell fits and save it. When I re-open the project around 80% of the time the problem occurs.
Symptoms: When I re-open the project around 80-90% of the time one or more of the following occurs:
- One of the quick shell paths completely loses all its information (including path information which isn't editable by the user, parameter info etc; see attached screenshot)
I believe that I have fixed this.
- Parameter info for one or more paths is reset to the default (i.e. if I've named a path delrauau it's renamed dr_ag_au_1)
Again, I believe that I have fixed this.
- In the GDS window starting values for parameters that have a non-zero starting value are set to their previously guessed value, rather than the starting value I set (ie. If I set ss as 0.003 and during the fit it is guessed to be 0.001 when I reopen the project the starting value will be set to 0.001) and "restrain" parameters are changed to "guess".
I have examined the history of your project. At no point is a fit saved with a restraint. The GDS windows is filled correctly according to the contents of your project file. Also, the initial guesses are all entered into the GDS window with the values I see in the history. Are you saying that you have made a restraint, saved the project, then had Artemis fail to remember that you had made a restraint?
- Phase correct fitting boxes are unticked (sometimes in an "impossible fashion" where the "plot with phase correction" option is set but no paths have the "use path for phase corrected plotting" option set)
I don't understand how that can be a problem. The default is not to plot with phase correction. I don't save the state of that button in the project file in any case. I need to do a bit more testing, hopefully I'll make a new trial release package for your to test before the end of the day. B
Attachments:
Noinfo.png - screenshot of Artemis when path info is lost Reset.png - screenshot of Artemis when parameter names are reset Dartemis.log - Artemis log file when opening a project that has this problem Artemis.fpj - Artemis project file that displays these symptoms.
Please let me know if you need further info/files.
Thanks,
Ian
Ps: OK, things got weird while preparing this bug report: The file in question stopped opening at all - Artemis loaded and went through loading fit x, x+1 etc., once it finished (not exactly sure what stage) it just closed. And then, after several attempts, started working again, as if by magic, before I'd saved a log file.... If I can figure out how to reproduce this I'll send more info...
-- Bruce Ravel ------------------------------------ bravel@bnl.gov National Institute of Standards and Technology Synchrotron Science Group at NSLS-II Building 535A Upton NY, 11973 Homepage: http://bruceravel.github.io/home/ Software: https://github.com/bruceravel Demeter: http://bruceravel.github.io/demeter/ _______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Hi Ian, Glad the QFS business seems solved. Thanks for that bug report.
Regarding the initial guesses this is what I experience (I've managed to understand the symptoms a bit more specifically now): I set up the initial guess values in the GDS window and run the fit. When I've finished working I save the project and exit. When I reload the project the initial guesses for guess parameters with an initial guess of 0 are set to the final guess from the previous fit (see attached screenshot of GDS + history window to demonstrate(artemis gds init guess 0 bug.png)).
Again, good eye. I was using the value of the initial guess as a logical flag to choose between the initial value and the best fit value as the value to display. An initial guess of 0, of course, evaluates false, thus it would display the best fit. That's just a silly programmer error and will be fixed in the next trial release.
Regarding the issue I mentioned at the start about reopening project files I made in 0.9.21 I've attached the following (project + logs from 0.9.21 and from similar issues I've experienced (very) intermittently in 0.9.20):
Project file saved in 0.9.21 that I can't reopen - artemis testing.fpj Log file from trying to open it (0.9.21) - dartemis.log
Project file saved in 0.9.20 that I can't reopen - dualedgefitting.fpj Log file from trying to open it (0.9.20) - dartemis_current.log
I will look into this, but not today. I was in a meeting since 9 am... :( B -- Bruce Ravel ------------------------------------ bravel@bnl.gov National Institute of Standards and Technology Synchrotron Science Group at NSLS-II Building 535A Upton NY, 11973 Homepage: http://bruceravel.github.io/home/ Software: https://github.com/bruceravel Demeter: http://bruceravel.github.io/demeter/
On 10/27/2014 10:53 PM, Godfrey, Ian wrote:
Project file saved in 0.9.21 that I can't reopen - artemis testing.fpj Log file from trying to open it (0.9.21) - dartemis.log
This one is a great example of the value of a trial release and, more importantly, an example of the *immense* value of helpful users like yourself. This triggered a use case I simply hadn't thought of, but which I now see will happen frequently using the 0.9.21_pre2 Windows package. Easy fix, happily.
Project file saved in 0.9.20 that I can't reopen - dualedgefitting.fpj Log file from trying to open it (0.9.20) - dartemis_current.log
Couldn't reproduce your problem, so this will take more attention. That's a job for tomorrow. B -- Bruce Ravel ------------------------------------ bravel@bnl.gov National Institute of Standards and Technology Synchrotron Science Group at NSLS-II Building 535A Upton NY, 11973 Homepage: http://bruceravel.github.io/home/ Software: https://github.com/bruceravel Demeter: http://bruceravel.github.io/demeter/
participants (2)
-
Bruce Ravel -
Godfrey, Ian