Ian, your post gave me a bit of deja vu. Bruce, that sounds very similar to a bug report I gave you (back when Demeter was in alpha?) on Nov 3 2011. You might want to check your personal Email, or I could forward a copy to the group. Even though it's many versions ago this might be a different facet of the same bug. Relevant text: "Take any of my "Ref" samples from the files I gave you and start a new file. (Alternatively, use any data you have.) Make a quick FS fit and let Artemis fill in the Path variables. (Although I see this on all types of fits, and when I write my own variables.) Make one fit with a "bad guess" for one parameter, like N*so2=1 for my FCC Pd, and for the next fit, make a proper guess of 12. (This is only to deliberately make fits with very different results; this may also work by varying the window, etc.) Copy the log for each result and set aside for a moment. Now, go to the GDS window and hit "Discard All." Go back to the History tabs and look at the fit parameters again. You should see the report from the last fit is unchanged, and the statistical parameters for the first fit are the same, but the guess parameters and everything below for the first fit are now overwritten by the values from the last fit." -Jason On Mon, Mar 9, 2015 at 9:18 AM, Bruce Ravel wrote:

On 03/09/2015 04:17 AM, Godfrey, Ian wrote:

...

In the history window some, but not all, data from previous fits seems to get overwritten when running a new fit. Specifically I've noticed this happening with the information in the "Data set" section. To reproduce run a QFS fit with some R-space fitting windows (say 2-4); at this point the log will be displayed correctly in the history window. Now change the R window (say 1.5-3.5) and run the fit again. When you go to the history window the R window information will be displayed correctly for the most recent fit but, for the previous fit it will have been overwritten by the newer fit. Some of the other info, such as R-factor by k-weight seems to get overwritten too.

A video of this behaviour can be found here: https://wwwa-e.ucl.ac.uk/cgi-bin/dropbox/dropbox.cgi?state= pickup_info&id=29d3e5c2 password: 54c8545f

System info: Win 8.1 Enterprise x64 running Demeter 0.9.22 pre release x64; log attached.

Ian,

First off, I really like your way of making a bug report. Your video makes the problem completely clear. (I also rather like your background image.) While all my worst days begin with email that starts "Sorry ... another bug report!", an unambiguous explanation makes me very happy.

As for the problem you are reporting -- yikes! That's really troubling. I'll look into it.

Cheers, 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/ _______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

Some of us are blessed with Fourier eyes, others with QFS memory. :) Honestly, I remembered because the event gave me an aversion to ever using QFS in a large Artemis project, and when I saw a similar issue on the list I recalled why I avoid QFS. I think in the changelog you mentioned whatever you did to fix my problem had some effect on how the fit history was saved, breaking compatibility with earlier versions. It seems (although you likely know much better) that there's some quirk about how QFS path data is saved which can (perhaps still) generate errors that are different and not as well-handled as atoms-derived path data. On Mon, Mar 9, 2015 at 2:55 PM, Bruce Ravel wrote:

Wow! Jason, that either impressive or really creepy!

I concur that those seem really similar. And I don't see any evidence in my change logs that I ever actually addressed that complaint. Apparently patience is a virtue. :)

Ian, Your plotting problem seems like an issue with your computer or your video card. I'm unable to reproduce it on any of my computers. B On March 12, 2015, at 12:22 AM, "Godfrey, Ian" wrote: Hi Bruce, The history seems to be working fine now, but I'll let you know if I encounter any more issues, thanks. As for the plots - I'm still experiencing the same issue, sometimes a line disappears; changing GNUPlot terminal doesn't seem to fix this. At the end of the day I think it's a problem I can live with, I only encounter it occasionally when I'm trying to zoom in to select a specific point accurately for something and I can scroll enough to get the line back... Thanks, Ian ps. My desktop image was cropped from an old railway ad: https://nationalrailwaymuseum.files.wordpress.com/2013/04/sspl_10173493_high... ---- 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 ________________________________________ From: ifeffit-bounces@millenia.cars.aps.anl.gov on behalf of Bruce Ravel Sent: 10 March 2015 17:50 To: XAFS Analysis using Ifeffit Subject: Re: [Ifeffit] Data being overwritten in Artemis history window On 03/09/2015 04:17 AM, Godfrey, Ian wrote:

In the history window some, but not all, data from previous fits seems to get overwritten when running a new fit. Specifically I've noticed this happening with the information in the "Data set" section. To reproduce run a QFS fit with some R-space fitting windows (say 2-4); at this point the log will be displayed correctly in the history window. Now change the R window (say 1.5-3.5) and run the fit again. When you go to the history window the R window information will be displayed correctly for the most recent fit but, for the previous fit it will have been overwritten by the newer fit. Some of the other info, such as R-factor by k-weight seems to get overwritten too.

I just pushed a fix for this to github and posted new windows installer candidates at http://bruceravel.github.io/demeter/#windows If you see any other questionable behavior in the history window let me know. I think I understood the ramifications of the fix I made, but I am not 100% certain. The windows installers also include the most recent version of gnuplot. Hopefully that will address your problem regarding zooming and scrolling. If it does not, try changing the gnuplot->terminal configuration parameter to "qt". qt is one of the other terminal options in the new version of gnuplot. It makes a pretty plot, but I like the controls on the wxt terminal more. If you are unsatisfied with that, try setting it to "windows", which is the third (and to my eye, the worst) of the three plot terminal options. Hopefully one of them will work for you. Cheers, 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/ _______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit _______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

On 03/15/2015 09:53 PM, Godfrey, Ian wrote:

This doesn't occur in the history window, but I can only reproduce it in 0.9.22 Pre 2 (not in Pre 1*) so I think it might be related:

I can't reopen any project files I saved in this version (I can reopen older files fine, though). Artemis loads as usual but, no sooner have all the windows appeared than they disappear again and Artemis shuts down.

I think you can reproduce this just by saving any project file and attempting to reopen it, but the following steps should definitely work:

1) Import Athena data 2) Setup QFS fit 3) Run the fit (optional) 4) Save the project 5) Close Artemis 6) Open the project by double clicking on it.

I've attached an Artemis log and project file. Windows 8.1 Ent x64, Demeter 0.9.22 pre 2 x64.

Actually, this is unrelated to the other problems you brought up recently. This was me trying solving another problem I had run into related to gnuplot, but not testing it very carefully. (Or at all!) Easily fixed. I just pushed the fix to the head of the github repository and I'll make a new trial installer later today. 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/

Hi Bruce,

Done. Let me know if you have any trouble downloading -- I have been teaching myself how to use the Amazon Web Services command line tool, which is very handy. I am mostly sure I have uploaded the installer packages correctly.

All downloaded and functioning correctly, thanks. I am seeing a (new) weird bug in plots (both in Athena and Artemis) on one PC though - see attached screenshot. I'm wondering if this could be related to the fact that I'm running a Japanese copy of Windows (although set to English) on this PC (I don't see the issue on my UK laptop)? The reason I suggest this is that backslashes in the GNUPlot script all seem to have been replaced by Yen symbols (see here for more: http://stackoverflow.com/a/6897500). I've attached a screenshot of the plot buffer showing the various yen symbols where their aught to be backslashes (I've highlighted the ones I think are causing the display issues) (I've tried to copy+paste it, but the yen symbols magically get replaced by backslashes when I do that so a screenshot will have to do!). (Also, the "about" button on the command buffer takes me here http://bruceravel.github.io/demeter/aug/monitor.html#thecommandbuffer, which is a 404.) Thanks, Ian