bruceravel
commented
4 years ago Hi Vasily, been a busy week so far, so sorry for the slow response. This is amazing! I have another busy day today, but I will look into your issues real soon.
Open LebedevV opened 4 years ago
bruceravel
commented
4 years ago Hi Vasily, been a busy week so far, so sorry for the slow response. This is amazing! I have another busy day today, but I will look into your issues real soon.
LebedevV
commented
4 years ago Hi Bruce,
I am writing to provide you with an update concerning the issues mentioned. It seems, that the second one has been caused by the issue with pre-compiled feff6/feff8l binaries distributed with larch, or (less likely) with the receiving fit results from larch. Demeter with ifeffit as a backend is working well. So, the question is - is it possible to compile, install, and run the ifeffit-based version of Demeter in the presence of larch?
Installation instruction for Gentoo linux:
emerge -av laymanlayman -a stuffemerge -av demeter. Some adjustments of local USE-flags might be required, one may use dispatch-conf to review and confirm changes.Best wishes, Vasily
newville
commented
4 years ago @LebedevV Well, are the pre-compiled versions of feff6l or feff8l running properly on your linux system? If not, what versions of gcc are being used? If ifeffit installs for you without incident, you're probably using a pretty old system.
The feff6l and feff8l binaries for xraylarch are built with fairly old versions of gcc and glibc (circa gcc 6, I believe - we should probably document that more clearly!). For sure, feff6l could be built with gcc4.8.5 (which happens to be what Centos7 provides by default), but feff8l will not build with that compiler version and needs at least gcc 4.9 (I think ;)). Personally, I consider "Centos7" - more than 5 years old - to be the current standard of "old enough to work for almost everyone".
As a general comment: it's probably better to understand why "latest code" isn't working than to try to get "very old code" to work. Like, whatever makes you think "very old version" is "better" is surely missing things that the developers put into "latest version". In this particular case, support for ifeffit ended (also about 5 years ago). So, if you want to use ifeffit and it builds, that is fine. I will not give any help, guidance, suggestions, or sympathy for using it and will not believe the results it gives unless verified by larch.
LebedevV
commented
4 years ago Dear Matt,
Thank you for the replay! I am using gcc10.2 - not sure, that "old" is a good description for this version. Iffefit compiles well, here are details of build instructions & patches from the Ubuntu/Debian package. For sure, I absolutely agree with your point concerning old versions. However, I have to mention, that one who wish to install Demeter needs in this ifeffit package anyway, as far as Demeter is looking for iffefit during the compilation and for tests.
Concerning to the larch and feff8 - for the moment I am using larch from PyPI or github as a source (gentoo packages are here, sorry for not adding dioptas&tomopy there, will do ASAP), but feff8l (as well as feff6l) is distributing there as a pre-compiled binary file. These files are not working "as is", the error message for feff8l is "undefined symbol: comdic_". So, as for me, it seems that I am missing some unobvious specific dependency, which I should mention in the package, or I have to replace feff8l_* with the locally compiled versions. Am I understand correctly, that for the second option I have to compile this code?
Concerning OSes - well, as an ordinary XAS user, I just have an Ubuntu in VBox for the data processing, but as a Gentoo user, who can create a package and put it in one of repos, I'd like to do that... at least, I would be able to compile and install larch, Demeter, and all deps in one command if I'd have to change a PC. Hope, other Gentoo users will find it useful, too.
Best, Vasily
newville
commented
4 years ago @LebedevV
Thank you for the replay! I am using gcc10.2 - not sure, that "old" is a good description for this version. Iffefit compiles well, here are details of build instructions & patches from the Ubuntu/Debian package.
OK. But I think your instructions and patches demonstrate my point very well: you need a pile of non-trivial patches even to get the code to compile. Who is going to maintain that, or even be able to understand it in a years time? That's to say nothing of what the code might be able to do.
For sure, I absolutely agree with your point concerning old versions. However, I have to mention, that one who wish to install Demeter needs in this ifeffit package anyway, as far as Demeter is looking for iffefit during the compilation and for tests.
Yes, demeter has a dependency that has not been supported for several years.
Concerning to the larch and feff8 - for the moment I am using larch from PyPI or github as a source (gentoo packages are here, sorry for not adding dioptas&tomopy there, will do ASAP)
It is fine with me to not include dioptas or tomopy. These are not needed for XAFS at all and they are clearly labeled as optional packages for Larch. These two are each a source of pain for packaging and maintenance. Code by beamline scientists... go figure.
but feff8l (as well as feff6l) is distributing there as a pre-compiled binary file. These files are not working "as is", the error message for feff8l is "undefined symbol: comdic". So, as for me, it seems that I am missing some unobvious specific dependency, which I should mention in the package, or I have to replace feff8l* with the locally compiled versions. Am I understand correctly, that for the second option I have to compile this code?
Well, compiling these yourself is OK, but I don't see why it should be needed.
There is a "comdic" structure in the Feff8l code, but not in Feff6l.
For me, with anaconda python on Fedora 32 (gcc 10.2.1) both feff6l and feff8l run to completion, giving sensible results. The executable files are in the /home/matt/anaconda3/lib/python3.8/site-packages/xraylarch-0.9.47-py3.8.egg/larch/bin/linux64/.
Running ldd on that feff6l and feff8l_* point to
That should work for many linuxes. Can you offer any insight into why it doesn't work for you?
Concerning OSes - well, as an ordinary XAS user, I just have an Ubuntu in VBox for the data processing, but as a Gentoo user, who can create a package and put it in one of repos, I'd like to do that... at least, I would be able to compile and install larch, Demeter, and all deps in one command if I'd have to change a PC. Hope, other Gentoo users will find it useful, too.
Oh, I don't mind using the Linux distribution of your choice - I have no complaint about that at all. I don't make packages for any Linux distribution and recommend against anyone doing that. Those will use system Python and Larch needs a lot of non-standard libraries for scientific computing and graphics. I would suggest using a dedicated environment and a system like Anaconda Python which allows all of the components to be installed in a user's folder without elevated permissions. As it happens, I do support exactly that (and would really like to be able to support a plain "pip install" into a users environment, but there are still some things not working for that, especially on Linuxes). Of course, if an end-user wants to install as root to a system Python environment, that should be OK.
Anyway, I am curious if you can provide some insight about why the binary feff6l and feff8l_xxx don't work for you?
LebedevV
commented
4 years ago @newville
Who is going to maintain that, or even be able to understand it in a years time? That's to say nothing of what the code might be able to do.
Absolutely agree, but, to be honest, - what else can I do to run Demeter? Actually, I just figured out that on Ubuntu@VBox I was using it with ifeffit as a backend, too... I am puzzled now - is it actually possible to run fits in Artemis using Larch? I am observing a number of similar errors on different systems, presumably caused by problems in artemis/larch interaction, but now I am sure that Larch itself is working as planned: I used conda installation on Ubuntu, and just added this weird patch to allow demeter to start/stop the Larch server.
It is fine with me to not include dioptas or tomopy
Anyway, I am going to do that once, because primarily I am TEM microscopist, so highly likely I will need in a tomopy as soon as I'll figure out how to deal with gatan dm3/dm4 there - however, it is another story.
There is a "comdic" structure in the Feff8l code, but not in Feff6l.
For feff6l the error has been "undefined symbol: clmz_"
Anyway, I am curious if you can provide some insight about why the binary feff6l and feff8l_xxx don't work for you?
Thank you very much for the data provided, it was really helpful! The problem was caused by the strip, performed by the package manager for all binaries by default. I overrode this option for xraylarch, and systemwide installed binaries seem to be working now - at least, feff works from start to end and produces chi.dat and xmu.dat files. However, I'd be glad to know - is there any working testsuite for feff? I found some here, but it seems to be aimed to the old version of larch. Also, I've tried to compile feff8l from sources with gcc10.2, and not actually succeeded, but it should be fine as far as it is possible to run pre-compiled binaries now.
I don't make packages for any Linux distribution and recommend against anyone doing that.
Make sense, indeed. In my case, the creation of the package for Larch&its dependencies (fortunately, it is quite easy for Gentoo) has been a part of attempts to install&run Demeter. To be honest, the error message "Ifeffit is not available. Install Larch to use Demeter." is a bit confusing, however, as a result now I have these Gentoo packages.
Thanks again!
Best wishes, Vasily
newville
commented
4 years ago On Sun, Sep 27, 2020 at 9:05 AM VasilyLebedev notifications@github.com wrote:
@newville https://github.com/newville
Who is going to maintain that, or even be able to understand it in a years time? That's to say nothing of what the code might be able to do.
Absolutely agree, but, to be honest, - what else can I do to run Demeter? Actually, I just figured out that on Ubuntu@VBox I was using it with ifeffit as a backend, too... I am puzzled now
Yeah, me too!
- is it actually possible to run fits in Artemis using Larch?
Yes, or at least it should be. If you're having problems with this, please explain the problem you are having in enough detail to be able to understand what could be going on. So far, all I can understand is that it is not working for you.
I am observing a number of similar errors https://pastebin.com/gxGjbkBD
on different systems, presumably caused by problems in artemis/larch interaction
I have no idea what an sp file is. It's not uncommon that the cache has
to be cleared.
, but now I am sure that Larch itself is working as planned: I used conda
installation on Ubuntu, and just added this weird patch https://github.com/LebedevV/stuff/blob/master/sci-physics/xraylarch/files/weird_patch_for_demeter to allow demeter to start/stop the Larch server.
Um, yeah that is weird, and kind of hard for me to believe. It is not as weird as neither feff6l nor feff8l being able to run. I just cannot tell what might be going on.
It is fine with me to not include dioptas or tomopy
Anyway, I am going to do that once, because primarily I am TEM microscopist, so highly likely I will need in a tomopy as soon as I'll figure out how to deal with gatan dm3/dm4 there - however, it is another story.
There is a "comdic" structure in the Feff8l code, but not in Feff6l.
For feff6l the error has been "undefined symbol: clmz_"
Anyway, I am curious if you can provide some insight about why the binary feff6l and feff8l_xxx don't work for you?
Thank you very much for the data provided, it was really helpful!
What does ldd show for the feff6l and feff8l executables?
The problem was caused by the strip, performed by the package manager for
all binaries by default. I overrode this option for xraylarch, and systemwide installed binaries seem to be working now - at least, feff works from start to end and produces chi.dat and xmu.dat files.
Sorry, I don't understand what you are saying: what system-wide binaries? I thought you said you used anaconda python.
However, I'd be glad to know - is there any working testsuite for feff? I
found some here https://github.com/xraypy/feff85exafs/tree/master/tests, but it seems to be aimed to the old version of larch.
Yes, that is the test suite for Feff8 that Bruce put together.
Also, I've tried to compile feff8l from sources with gcc10.2, and not
actually succeeded https://pastebin.com/Cf1ufwFs, but it should be fine as far as it is possible to run pre-compiled binaries now.
Yes, I do see a problem building feff8 with more modern compilers. I'll fix that soon. I also see some problems with the test framework that I'll fix too.
But this should all be separate from the version of feff6l or feff8l
distributed with Larch not running. I simply do not understand why you are
getting those errors. Can you give any more insight? Like, what does
ldd say for these and why did they get stripped for you? How did you
install larch?
I don't make packages for any Linux distribution and recommend against
anyone doing that.
Make sense, indeed. In my case, the creation of the package for Larch&its dependencies (fortunately, it is quite easy for Gentoo) has been a part of attempts to install&run Demeter.
It looks to me like you applied a large number of non-trivial patches.
To be honest, the error message *"Ifeffit is not available. Install Larch
to use Demeter."* is a bit confusing, however, as a result now I have these Gentoo packages.
Sorry, I don't understand what is confusing about that message.
LebedevV
commented
4 years ago @newville ,
Sorry for the delay with the answer, I've spent some time, reproducing the issue by different ways on different installation sequences.
If you're having problems with this, please explain the problem you are having in enough detail to be able to understand what could be going on.
So, let's have a look at the basic installation of Demeter on the Ubuntu 18.04 (there is no ifeffit package in 20.04, as I can see). I used slightly modified instructions, full installation details list is here. Virtual drive of 20Gb volume was used. On this step, one has a working Demeter from git (master branch) with ifeffit as a backend, no larch installed. Trying to do a basic analysis for FeS2 example, namely:
No any software issues observed at this point.
Install Larch and remove old Demeter settings: $cd $wget https://millenia.cars.aps.anl.gov/xraylarch/downloads/xraylarch-0.9.47-Linux-x86_64.sh $sudo chmod 1777 xraylarch-0.9.47-Linux-x86_64.sh $./xraylarch-0.9.47-Linux-x86_64.sh <defaults, "Do you wish installer to initialize xraylarch" yes> $rm -rf ~/.horae $sudo init 6
Now, when I am trying to import xmu file by Athena, I see the import warning "Could not read <...>.xmu as either data or a project file. Do you need to enable a plugin?". No success, close Athena, errror log from the console is here. I am trying to open the final Artemis project, and it just fails. Log is available here. ...and actually that's it - here is the first problem. Please, let me know, if I am doing something wrong, but as for me, it seems like a pretty standard installation.
As far as these errors in console looks exactly like ones, which I've already met on Gentoo, one may try to apply the same previously discussed workaround, just to add a line to print the port number of the Larch server. Again, not sure, why it is working, but it allows Demeter to establish the connection to the server.
Now:
In Artemis' preferences changing feff executable to "feff6l", restart. Now Atoms work, FSPath/SSPath fits fails with the same errors. $rm -rf ~/.horae
The same, but feff8l as executable for feff:
The observed problems are very reproducible, so I am not sure, how can I run larch as a backend of Artemis. Will be grateful for any advices, can provide you with all the necessary information - or share the VBox drive, if it will help.
I have no idea what an
spfile is. It's not uncommon that the cache has to be cleared.
Am I understand correctly, that "$rm -rf ~/.horae" should clear the cache?
What does
lddshow for the feff6l and feff8l executables?
On Ubuntu-18.04, larch installed from xraylarch-0.9.47-Linux-x86_64.sh - here
Sorry, I don't understand what you are saying: what system-wide binaries? I thought you said you used anaconda python.
But this should all be separate from the version of feff6l or feff8l distributed with Larch not running. I simply do not understand why you are getting those errors. Can you give any more insight? Like, what does
lddsay for these and why did they get stripped for you? How did you install larch?
Apologize for mixing up different issues, that was about Gentoo installation, we can leave it for the clarity. For Ubuntu I am using anaconda-based installation, and feff binaries works well - but not Artemis, see above. For Gentoo I am using systemwide installation, and switched off strip, so it works now exactly like on Ubuntu. However, if by some reason you'd like to have a look on ldd of stripped binaries ("strip --strip-unneeded", default behaviour of the package manager), it is here. Please, let me know, if you'd like to have more data on this issue.
Yes, that is the test suite for Feff8 that Bruce put together.
Great! I'll try to use it, thank you.
It looks to me like you applied a large number of non-trivial patches
Sure, you are right. From the other side, when one is doing "apt-get install ifeffit" on Ubuntu, he is actually installing iffeffit with almost the same set of patches, see the raw package itself, so I do not see much harm in that, to be honest.
Sorry, I don't understand what is confusing about that message
I might be wrong, but one may (mis)understand from this message as that it is enough to install Larch to get ifeffit, and the problem is not in the absence of the ifeffit binaries, which Demeter is looking for on this stage, but in the Larch installation issues - as I did some time ago...
Thank you very much for your time and patience!
Best wishes, Vasily
newville
commented
4 years ago @LebedevV it is very hard to comment on all of these different issues. But, for sure there were problems in xraylarch 0.9.47 with the Linux binary libraries and with the way demeter expected larch_server to respond. I think these are now fixed in 0.9.48 (not completely released yet as I have not built a Windows installer yet). I haven't tested everything, partly because I cannot build demeter on Fedora 32 ... maybe that is "yet"...
Anyway, some of the issues you're having might be fixed with https://millenia.cars.aps.anl.gov/xraylarch/downloads/xraylarch-0.9.48-Linux-x86_64.sh
If you get a chance to try this out, please let me know how it goes...
LebedevV
commented
4 years ago @newville , Many thanks, now Demeter is able to manage the connection to the Larch server. Binaries feff6l and feff8l itself are working, too. However, I have not found any way to force Artemis to work with feff6l or feff8l, I am still getting the same errors as before, like "Error reading file /home/guest/.horae/stash/_dem_rijjpfow/feff/rjnvv/pbgazasqh.sp"
Actually, I have built Demeter on Fedora32 with pre-installed Larch - and I am observing exactly the same errors as on Ubuntu and Gentoo. To compile it, I have installed a few packages (see the details), and masked ifefffit mentions in the DemeterBuilder like here. Also, I switched a feff version to feff8l in Artemis settings, as far as no feff6 is available.
newville
commented
4 years ago @LebedevV Glad to hear it is working better for you. I have to admit that I think I still may not be understanding everything here:
However, I have not found any way to force Artemis to work with feff6l or feff8l
Hm, you mean you cannot set which Feff version to run at all? Is Artemis able to run any version of feff?
I am still getting the same errors as before, like "Error reading file /home/guest/.horae/stash/_dem_rijjpfow/feff/rjnvv/pbgazasqh.sp"
I don't know what the sp files are, but I think you might need to remove everything in this stash directory.
I have not tried building Demeter on Fedora 32 recently, but when I tried a few months ago I ran into a few problems. I think PDL may now be fixed but I could not get Perl+Wx to work at all. Maybe I should look again... Anyway, that's just to say that I cannot try to reproduce your observations, and I cannot guess what you might mean. That is you say "no feff6 is available" but I thought you said you had the binary, no?
LebedevV
commented
4 years ago @newville , Thank you for your reply!
Hm, you mean you cannot set which Feff version to run at all?
Well, technically speaking, I can set it, but it will not run As I can see, in all three OSs which I tested, Artemis is not working with feff6l or feff8l.
Is Artemis able to run any version of feff?
The only one which I succeeded with is feff6 from iffeffit in the absence of Larch
Error details (Ubuntu) for feff6l:
Athena works as I expected it to, with some minor differences from the previous run Artemis can import the obtained file, can create FSPath&corresponding GDS, but fit fails Artemis can not import .inp file ("can not find data file @&^null^&@") Artemis can import final project, can fit it, but resulting R-factors of 0.00 looks strange, see log
for feff8l:
Artemis can import the Athena project, and generate FSPath. Fit fails with the error "*.sp file not found" Artemis can start the procedure with Atoms (in configuration Atoms-feff_version switched to 8) and generate the output file, however, feff fails with the following message.
I don't know what the sp files are, but I think you might need to remove everything in this stash directory.
I was doing rm -rf ~/.horae, then settings change, then test. Is it sufficient?
I think PDL may now be fixed but I could not get Perl+Wx to work at all
I see... Well, fortunately, I have not met any difficulties there - but I installed PDL and perl-Wx via yum as packages perl-PDL and perl-Wx. Full list of installed packages is yum install apper git gfortran make gnuplot libpng-devel perl-local-lib perl-PDL perl-CPAN perl-XML-Parser perl-RPC-XML httpd-devel wxGTK3-devel perl-Wx wxWidgets
That is you say "no feff6 is available" but I thought you said you had the binary, no?
Sorry for that, I meant that on Fedora I do not have iffefit and the corresponding feff6 binary, so I can not run Artemis with the default settings. Hence, I need to override "feff binary" variable to "feff6l" or "feff8l".
newville
commented
4 years ago On Tue, Oct 27, 2020 at 6:24 AM VasilyLebedev notifications@github.com wrote:
@newville https://github.com/newville , Thank you for your reply!
Hm, you mean you cannot set which Feff version to run at all?
Well, technically speaking, I can set it, but it will not run As I can see, in all three OSs which I tested, Artemis is not working with feff6l or feff8l.
I do not see that.
Is Artemis able to run any version of feff?
The only one which I succeeded with is feff6 from iffeffit in the absence of Larch
Error details (Ubuntu) for feff6l:
Athena works as I expected it to, with some minor differences from the previous run Artemis can import the obtained file, can create FSPath&corresponding GDS, but fit fails https://pastebin.com/MQa0NDZF
I'm not sure I would call that "fails"? Are you absolutely certain that the inputs are ok?
Artemis can not import .inp file ("can not find data file @&^null^&@") Artemis can import final project, can fit it, but resulting R-factors of 0.00 looks strange, see log https://pastebin.com/kaEX0NVq
That looks to me like the fitting code ran - it reports best-fit values and uncertainties. I don't know why the Path Parameters are zero. I don't know how your model is set up.
How could the fit have run if the input file could not be found?
for feff8l:
Artemis can import the Athena project, and generate FSPath. Fit fails with the error "*.sp file not found" Artemis can start the procedure with Atoms (in configuration Atoms-feff_version switched to 8) and generate the output file, however, feff fails with the following message https://pastebin.com/3uRUBYXm.
Um, again feff8l definitely ran and did stuff. Do you know your input is OK?
I don't know what the sp files are, but I think you might need to remove
everything in this stash directory.
I was doing rm -rf ~/.horae, then settings change, then test. Is it sufficient?
Probably. I don't know how these are used.
I think PDL may now be fixed but I could not get Perl+Wx to work at all
I see... Well, fortunately, I have not met any difficulties there - but I installed PDL and perl-Wx via yum as packages perl-PDL and perl-Wx. Full list of installed packages is yum install apper git gfortran make gnuplot libpng-devel perl-local-lib perl-PDL perl-CPAN perl-XML-Parser perl-RPC-XML httpd-devel wxGTK3-devel perl-Wx wxWidgets
That is you say "no feff6 is available" but I thought you said you had the binary, no?
Sorry for that, I meant that on Fedora I do not have iffefit and the corresponding feff6 binary, so I can not run Artemis with the default settings. Hence, I need to override "feff binary" variable to "feff6l" or "feff8l".
OK, I would read that and say that it is available.
I don't what is going on. Does your fit work with a basic Larch script?
Hi Bruce,
Thank you very much for your software! As a relatively frequent user, after migration on the Gentoo Linux I wrote ebuilds for Ifeffit, Xraylarch, and Demeter, so now any Gentoo user can easily install it with all deps from the ::stuff overlay.
The configurations is:
Demeter (git) is installing, passing tests and partially works, but a couple of bugs were observed there. Unfortunately, I was able to fix only one of them:
1) (somehow fixed) larch server not always correctly responds to 'start'/'stop'. In these cases, the Hephaestus app unexpectedly crashes. As a workaround, I added one "print" line to the xmlrpc_server.py of larch, see a patch, and surprisingly it works now. 2) (not fixed) The installed version of Artemis has an issue with fits - pressing of Fit button results in Demeter::UI:Artemis warning "Use of uninitialized value in subtraction (-) at /usr/local/lib64/perl5/Demeter/Data.pm line 983.". After the fit, reduced chi-square and R-factors are equal to 0. Chi-square and R-factors for separate k-values looks a bit better, however, it seems like an issue. I understand, that it pretends to be the installation or configuration problem, but currently I am out of ideas on how to fix it.
I will be grateful for any advice or ideas!
Best wishes, Vasily