- Ifeffit - millenia.cars.aps.anl.gov

Re: [Ifeffit] Problem with Perl interpreter
by Wojciech Olszewski 16 Nov '15

16 Nov '15

On 11/13/2015 11:41 AM, Bruce Ravel wrote: >Hi Wojciech, > >Why are you installing perl independently of Demeter? Do you have some other use on your >computer that requires you to install perl? Installing another version of Strawberry Perl is >almost certain to clobber Demeter. Demeter is currently using perl 5.18, which is not binary >compatible with 5.22. So, when you install the other version of perl things will break. If you >take care to install a very recent version of Demeter to a different installation directory >than you use to install Strawberry 5.22, it is possible that the two can be made to co-exist. > >If you install them to the same installation folder -- say C:\strawberry -- then Demeter is >guaranteed to be broken be due to the binary incompatibility. So ... did you install the other >version of perl prior to noticing that Demeter was broken? If so, there are ways to proceed, >but it may get a bit complicated. At the very least, you can uninstall both packages completely >then resinstall Demeter. That should leave you with a functioning Demeter, but it may break >other software. Did you install Strawberry 5.22 because you have some other use for perl on >your computer? If so, can your other software work with the version of perl that comes with >Demeter? That is, do you really need Strawberry 5.22? Executive summary: I think you problem is >binary compatibility between perl version, of which you seem to have two on your computer. If >all of that doesn't solve your problem, it's going to take a lot more effort to troubleshoot >the problem. >Good luck! >B Dear Bruce, The timeline of this problem was as follows: 1) Demeter was working fine; 2) One day I couldn't run any of the Demeter software - error message "Per interpreter has stopped working; 3) Reinstallation of Demether - the problem is still there; 4) Installation of perl (in other folder, not the same as Demeter) - the problem is still there; 5) Mail to mailing list; 6) Deinstallation of Demether and Perl; 7) Installation of Demeter. Unfortunately the problem is still there. I receive the same error message. Best regards, Wojciech -- ALBA Synchrotron <http://www.albasynchrotron.es> Wojciech Olszewski BL22 - CLAESS: Core Level Absorption & Emission Spectroscopies - Experiments Division ALBA SYNCHROTRON LIGHT SOURCE Ctra. BP 1413 km. 3,3 | 08290 | Cerdanyola del Vallès| Barcelona | Spain <http://www.albasynchrotron.es/AboutUs/Access> (+34) 93 592 4059 www.albasynchrotron.es <http://www.albasynchrotron.es>| wolszewski(a)cells.es <mailto:wolszewski@cells.es> **Please, do not print this e-mail unless it is absolutely necessary. **Si heu rebut aquest correu per error, us informo que pot contenir informació confidencial i privada i que està prohibit el seu ús. Us agrairíem que ho comuniqueu al remitent i l'elimineu. Gràcies. Si ha recibido este correo por error, le informo de que puede contener información confidencial y privada y que está prohibido su uso. Le agradeceré que lo comunique a su remitente y lo elimine. Gracias. If you have received this e-mail in error, please note that it may contain confidential and private information, therefore, the use of this information is strictly forbidden. Please inform the sender of the error and delete the information received. Thank you.

2 1

Re: [Ifeffit] Demeter under El Capitan
by Fowler, Joseph W. 15 Nov '15

15 Nov '15

Dear Matt, I’m the official MacPorts maintainer for Demeter. I am an amateur at this (i.e., at Ports), but I do have notes somewhere on how to update the port file (and, indeed, where to find it in the first place!). Concerning the long list of dependencies: I was unaware of the size of this list. I agree. It sounds crazy to think that we need THREE non-clang compilers to build demeter. I know the fellow who was the previous maintainer, and he has a bit of a superstitious belief in the powers of gcc. Perhaps he imposed this belief unnecessarily on us all? It sounds to me like you understand the internals of what demeter uses and how, much much better than I do. Let me suggest that you either contact me privately OR file a trac ticket at MacPorts about this. Either way, include details of what you think plausibly might be false dependencies. Of course, we’ll also want to add the new Perl dependencies that you pointed out. Perhaps then I can patch the port file and get your assistance in testing it in some way? Once we have a patch we like, I don’t have the powers to commit it to the MacPorts repository directly, but I can certainly make a request for a commit (they are pretty fast and responsive about that). I’d like to comment also on the time it takes to install MacPorts. The whole MacPorts concept supports installing from source AND installing pre-built binaries. The catch (as I understand it) is that the server resources that they use to build and serve the binaries are donated by a large corporation (one with a strong interest in selling more Macintosh computers, naturally). Thus the open-source Ports team cannot simply make the binary “buildbots” appear at will. An early adopter of an OS X version has to install every port, even the incredibly complex ones, from source. Again, I could be wrong, but I think that El Capitan is still in this state. See https://trac.macports.org/ticket/48609 and http://macports-dev.macosforge.narkive.com/tRq2luOR/el-capitan-buildbot for some additional info. Now, this is not to say that Homebrew is a worse solution than MacPorts. I have no basis for comparison (though here is one clue: many packages that I use within the Julia language depend on Homebrew for further dependencies, and I have noticed that they manage to Just Work). But I did want to defend MacPorts from the implied charge that it will always take all users ten hours to install a working system. If you can find a Homebrew expert to work with and develop a Demeter solution, that’s great. Here in my group at NIST, we use MacPorts for so many things that I’m sure we’ll continue to maintain the port file for the foreseeable future. Best wishes, Joe Fowler On Nov 13, 2015, at 11:00 AM, <ifeffit-request(a)millenia.cars.aps.anl.gov<mailto:ifeffit-request@millenia.cars.aps.anl.gov>> <ifeffit-request(a)millenia.cars.aps.anl.gov<mailto:ifeffit-request@millenia.cars.aps.anl.gov>> wrote: From: Matt Newville <newville(a)cars.uchicago.edu<mailto:newville@cars.uchicago.edu>> Subject: Re: [Ifeffit] Demeter under El Capitan Date: November 13, 2015 at 9:34:31 AM MST To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov<mailto:ifeffit@millenia.cars.aps.anl.gov>> Reply-To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov<mailto:ifeffit@millenia.cars.aps.anl.gov>> Hi George, All, Some progress: The MacPorts folks fixed the problem with PDL so that a 'port selfupdate' will then allow PDL to build and then install. With that, Demeter then installs, though there are some warnings about missing dependencies (Heap, XMLRPC::Lite, File::Slurp::Tiny, Encoding::FixLatin::XS) which I'm guessing are relatively new dependencies, not included in the Portfile. I installed these missing perl modules using the 'perl -MCPAN -e shell' The basic Athena and Hephaestus and Artemis run OK, though I haven't done exhaustive testing. I did have to change the default gnuplot terminal from Qt to wxt for each of Athena and Artemis (I did not try plotting with Hephaestus). The settings page for Artemis is not easy to find -- it might be that the multiple-small-screen layout is difficult to map to the Mac window styling. As for Xorg vs XQuartz: The correct answer should be "neither". Neither Demeter nor gnuplot actually use X11 at all -- both are using wxWidgets, which does not use X11 on Mac. Similarly, I cannot understand the dependency on all of llvm, gcc4.9, and gcc5.2 from MacPorts. Most of the code even for MacPorts appears to be built with the *system* (ie, Apple-supplied) clang compiler. I can believe it "necessary" (well, really, "easiest") to build all of gcc to get gfortran, but not twice. And, yeah, if you have to install from source, it sort of matters. I do not know where to update the MacPorts Portfile. All links to the actual portfile scripts seem broken to me, but maybe they're available someplace. --Matt

2 1

Demeter under El Capitan
by Fowler, Joseph W. 13 Nov '15

13 Nov '15

Bruce, Scott, Manuel: I’m the MacPorts maintainer for demeter and ifeffit, but I’m afraid I have not been much help lately. I’m sorry that I have not chimed in about any of the recent reports Mac / Macports problems under El Capitan. It so happens that my employer (US National Institute of Standards and Technology) does not let us upgrade to Yosemite OR El Capitan. They own the only Macs to which I have access, so I can only work under Mavericks. I’m afraid that artemis, hephaestus, and athena all start properly for me. To Manuel from Grenoble, all I can say is that xorg-server has a lot of dependencies, and it will take a long time to install the needed ports the first time. I would not think an entire hour is out of the question, depending on your connection speed and computer performance. To the others having trouble running (as opposed to installing), I wonder if anyone in the community is having success with the demeter suite under El Capitan? If so, we’d all be grateful if you could let us know what tricks were required. I am totally helpless on OS 10.10 and 10.11-specific problems. Joe Fowler NIST Boulder Laboratories

6 13

Apparent bugs in Athena 0.9.24 running under Windows 7 64 bit
by Marcelo Eduardo Alves 13 Nov '15

13 Nov '15

I have run another example file (Au+Cyanobacteria) downloaded from https://github.com/bruceravel/XAS-Education in Athena 0.9.24 under Windows 7 64 bit using two different Dell computers and observed the following apparent bugs: In both computers the orange points that indicates the E0 and the limits of pre and post-edge fittings did not appear in the plots; In both computers the legends did not appear in all plots; the same for the axes's scales and titles. The LCF plot showed just the sample and the fitted normalized ones even when the standard ones were required; In one computer, there were just two choice options for the standards; in the other one these boxes worked normally and all standards could be considered. Some screenshots are attached to this message, Marcelo.

2 1

Apparent bugs in Athena 0.9.24 under windows 7 64 bits - corrigendum
by Marcelo Eduardo Alves 13 Nov '15

13 Nov '15

Previous message: The LCF plot showed just the sample and the fitted normalized ones even when the standard ones were required Corrigendum: In fact, this is working in both computers, i.e., all plots appear in the graph; however, in one machine the legend, the axes´s scales, and the axes´s titles are not diplayed. M.

1 0

Re: [Ifeffit] Problems with EXAFS Fitting of Metalloprotein Zinc Samples
by Carolyn Carr 12 Nov '15

12 Nov '15

Hi Bruce, Thanks so much for clarifying that for me! I have been basing my fitting in R-space off of XAFS spectroscopy; fundamental principles and data analysis DOI 10.1023/A:1019105310221 which has a section on fitting in R-space over k-space although it is very possible I misinterpreted its analysis. My zinc question is more of a query rather than a true problem, and so I am glad that you have taken time to correct my knowledge of how fitting works. Carolyn Carr

3 2

LCF, Sayers & Bunker, R and ATHENA
by Florian Werner 12 Nov '15

12 Nov '15

Dear mailing list, we recently published a paper where we broke with the "Sayers & Bunker 1988 - Paradigm" to apply normalization as consistently as possible between samples and standards when performing linear combination fitting: http://pubs.acs.org/doi/abs/10.1021/acs.est.5b03096. There, we showed that for known mixtures of phosphorus standards the LCF of P K-edge XANES spectra delivers better results when changing the base-line and normalization parameters of the sample (in defined ranges, using the software /R/). I'm writing to the mailing list of several reasons: 1) A reviewer explicitly asked to contact Bruce Ravel so that the new insight could be implemented in ATHENA, 2) I was trying to combine my code with ATHENAs way of LCF before publishing the code. Unfortunately, I have not been able to resolve that a combination of both approaches results in large numbers of LCF procedures (sometimes Million or Billion). So many procedures are not fittable in reasonable time, maybe because my code is slow or maybe because /R/ isn't fast enough (or just the nlsLM-function that I'm using for LCF). I'm stuck and maybe programming in Perl would be a better choice (never programmed in Perl, yet)? Maybe a different kind of fitting algorithm would be faster?, 3) When using the nlsLM-function to perform LCF in /R/, I also have to provide portions of the standards before starting the fit. I used the same approach as ATHENA, dividing 1 by the number of standards so that every standard has the same portion. However, when playing with the code I realized that changing the starting portion can have an impact on the fitting result. Has this been observed or tested before by anyone else? How do you, in general, justify using the same starting portion for every standard? 4) Some minor question about LCF in ATHENA: a) Could the standards (the columns) in the output .csv-file after LCF be sorted alphabetically?, b) Does LCF in ATHENA sometimes produce negative numbers of a portion because the weight of any "last" standard in a set is always calculated by "1-sum(portions_of_other_standards)" (could it be this? https://github.com/bruceravel/demeter/blob/master/lib/Demeter/LCF.pm#L375-L…) To mimic "all samples sum to one" from ATHENA and to not produce negative portions, we used all LCF results which have a residual "absolute(1-sum(portions_of_all_standards)) < 0.0005"; maybe this is of interest also for ATHENA? Cheers, Florian

3 3

Problems with EXAFS Fitting of Metalloprotein Zinc Samples
by Carolyn Carr 11 Nov '15

11 Nov '15

Hi, I have a general question rather than specific. I have only ever fit XAS data on metalloproteins and one feature that I see is that when fitting Zinc samples in R-space there is no local minima. For Cobalt and Nickel samples I typically get one or a few fits that are obviously significantly better in R-factor (with reasonable distances, sigma^2, etc) but for Zinc this is not the case. I can get many good fits and Zinc likes to increase the coordination up to 8 for all data sets I have ever fit, although there is obviously no physical basis in this. This is true of not just my own proteins but Zinc samples made by collaborators, and after looking through previous group members fit tables, they had similar issues. My understanding is that one of the benefits of fitting in R-space is that there is a local minima, whereas in k-space there are many minima. I was wondering if there was a physical basis for this feature in Zinc samples, or if perhaps my group is not aware of some experimental setup that we should be doing for Zinc that would resolve this problem. Thank you for any help regarding this matter, Carolyn Carr

4 3

Problems with EXAFS Fitting of Metalloprotein Zinc Samples
by Carolyn Carr 10 Nov '15

10 Nov '15

Hi Robert, Thanks for your reply. We have done this with standard samples and we see the same thing. And of course, we can tell qualitatively from the XANES that our sample is not 8 coordinate, and not even 6 coordinate. We have never tried changing the temperature but we can try this the next time we go to SSRL. We actually do fit multiple scattering features as imidazoles which is one of the things we consider as a strength of Artemis for our basic needs. This is part of why we think this is strange, because putting 8 imidazoles around a zinc seems kind of silly but it likes it. 5 imidazoles and 3 sulfurs and I have an R-factor of 0.2% every time. If there is non standard multiple scattering that occurs in multiple unrelated proteins from different organisms then we would have no idea what this could be. Thanks for your comments! Carolyn Carr

2 1

Re: [Ifeffit] Ifeffit Digest, Vol 153, Issue 12
by Marcelo Eduardo Alves 09 Nov '15

09 Nov '15

I have downloaded the zip-file containing the example files and extracted them into other subfolders (i.e. C:\Users\Marcelo\Documents\1.Athena Calibração e Alinhamento\Examples\Fe foil). I think that this was my error. When I use C:\Fe foil the file was opened in Athena without any issue. Thank you Robert and Guanghui 2015-11-09 16:24 GMT-02:00 <ifeffit-request(a)millenia.cars.aps.anl.gov>: > Send Ifeffit mailing list submissions to > ifeffit(a)millenia.cars.aps.anl.gov > > To subscribe or unsubscribe via the World Wide Web, visit > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > or, via email, send a message with subject or body 'help' to > ifeffit-request(a)millenia.cars.aps.anl.gov > > You can reach the person managing the list at > ifeffit-owner(a)millenia.cars.aps.anl.gov > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ifeffit digest..." > > > Today's Topics: > > 1. Opening "older" data files in the latest Athena version > (Marcelo Eduardo Alves) > 2. Re: Opening "older" data files in the latest Athena version > (Robert Gordon) > 3. Re: Opening "older" data files in the latest Athena version > (Guanghui Zhang) > 4. Problems with EXAFS Fitting of Metalloprotein Zinc Samples > (Carolyn Carr) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 9 Nov 2015 15:41:33 -0200 > From: "Marcelo Eduardo Alves" <mealves.esalq(a)usp.br> > To: <ifeffit(a)millenia.cars.aps.anl.gov> > Subject: [Ifeffit] Opening "older" data files in the latest Athena > version > Message-ID: <97FB7D67CF2142A48FA29F9776D0A164@MarceloPC> > Content-Type: text/plain; charset="iso-8859-1" > > Dear all, > > I am using the latest version of Demeter (0.9.24) and I have downloaded > the data files available at https://github.com/bruceravel/XAS-Education. > > However, I am not being able to open the example files in Athena (e.g., > Fe.060 of Fe foil folder). > > Please, would it be possible to open those example files in the latest > Athena version. > > Thank you. > > Marcelo. > > > _______________________________________ > Marcelo Eduardo Alves > Departamento de Ci?ncias Exatas - ESALQ/USP > Avenida P?dua Dias, 11 > 13418-900 Piracicaba-SP > Fone: 19-3429-4151- RAMAL 26 > Email: mealves.esalq(a)usp.br >

3 3