Menu
▾
▴
atcollab-general — general discussion of direction, development, and documentation for atcollab
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
|
| 2014 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(17) |
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
(6) |
Oct
(1) |
Nov
(1) |
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
(7) |
Jun
(1) |
Jul
(13) |
Aug
(18) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Musa, E. <ela...@de...> - 2021-06-25 13:39:06
|
Hi everyone, For Matlab AT there are some tutorials and manuals on the web, but I could not find similar things for pyAT. Do you have something like that? I'm a new PhD student starting to look into optics calculations and corrections, and it would be good if i can do some pyAT training first. Thanks, |
|
From: Rogers, W. (DLSLtd,RAL,LSCI) <wil...@di...> - 2020-05-12 13:34:23
|
Hi all, Just a note to say that I have added the capability to parse Elegant and Tracy lattice definition files in pyAT. If anyone is interested in this and has some lattice files that I can test with that will help me make the parsers more robust. Otherwise this will be included in the next release of pyAT. Cheers, Will -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom |
|
From: Rogers, W. (DLSLtd,RAL,LSCI) <wil...@di...> - 2020-02-27 10:29:38
|
Hi Thorsten, We're always happy to get new users of pyAT. There are some very simple examples in this file. Can you get them to work? https://github.com/atcollab/at/blob/master/pyat/pyat_examples.rst If not, I'll try to help. When you get them working, perhaps you can suggest a few more examples to add. Cheers, Will ________________________________ From: Thorsten Hellert <the...@lb...> Sent: 26 February 2020 18:33 To: atc...@li... <atc...@li...> Subject: [Atcollab-general] pyAT examples? Hi guys, I’ve used AT extensively but because of Matlab license issues on our cluster I want to utilize more pyAT on our lattice optimization process. Does anyone of you know of any examples that could give me a quick start in the evaluation of linear lattice properties like beta functions and tunes? Thanks! Thorsten _______________________________________________ Atcollab-general mailing list Atc...@li... https://lists.sourceforge.net/lists/listinfo/atcollab-general -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom |
|
From: Thorsten H. <the...@lb...> - 2020-02-26 18:33:27
|
Hi guys, I’ve used AT extensively but because of Matlab license issues on our cluster I want to utilize more pyAT on our lattice optimization process. Does anyone of you know of any examples that could give me a quick start in the evaluation of linear lattice properties like beta functions and tunes? Thanks! Thorsten |
|
From: Boukes, A. (Arnold) <AEW...@ov...> - 2019-06-07 23:45:29
|
Dear Friend, Trust this email finds you well? I have a business transaction for you to handle. Revert for details. Regard |
|
From: <wil...@di...> - 2017-08-30 16:23:06
|
Hi all, Just to note, if you have a Github repository called 'at' that was originally forked from 'willrogers/at', you should delete that one and fork the new one listed below. Cheers, Will ________________________________ From: Boaz Nash [boa...@es...] Sent: 30 August 2017 17:14 To: atc...@li... Subject: [Atcollab-general] continuing development of AT (Matlab + Python) on GitHub Dear all, Development of AT will now continue on GitHub: https://github.com/atcollab/at The recent AT2.0 release can now be found there, along with previous 1.4 versions, downloadable as zip files. Python development, pyAT also continues within this same git repository. Thanks to Will Rogers for moving the svn repository into its new git home! Let us know if you have a GitHub account and want to participate! Best Regards, Boaz -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom |
|
From: Boaz N. <boa...@es...> - 2017-08-30 16:14:18
|
Dear all, Development of AT will now continue on GitHub: https://github.com/atcollab/at <https://github.com/atcollab/at> The recent AT2.0 release can now be found there, along with previous 1.4 versions, downloadable as zip files. Python development, pyAT also continues within this same git repository. Thanks to Will Rogers for moving the svn repository into its new git home! Let us know if you have a GitHub account and want to participate! Best Regards, Boaz |
|
From: Boaz N. <boa...@es...> - 2017-08-30 07:37:09
|
Thank you, Eugene. Thanks for your help also. My position at ESRF will be ending next week, so I will have less direct connection with the AT development going on at ESRF. I will be starting a new position at the company RadiaSoft (http://radiasoft.net/ <http://radiasoft.net/>) in Boulder, Colorado, in October. I expect that I can continue work on AT in some form with RadiaSoft, but I don’t expect to be able to be the main coordinator for the AT collaboration. I hope that others can step up to fill this role. I think that GitHub will give us some new tools for helping to manage the development. We already have 7 developers signed up under the atcollab org. on Github: https://github.com/atcollab <https://github.com/atcollab> I think one of the issues we need to resolve is who is responsible for which parts of the code, documentation, etc. In GitHub, the way it works is that people make changes to a part of the code in their local git repository. They then issue a “pull request”. Someone needs to decide whether or not to accept this pull request, which then merges the changes into the main repository. So far, everyone we’ve added to the atcollab organization is listed as “owner” meaning they fave full rights for editing and accepting pull requests. I think we should continue to go ahead with this sense of mutual trust, but also figure out who is responsible for what. We don’t want to put people in the position of having to accept code that they don’t understand. Having a robust set of testing routines would definitely help this situation. Looking forward to seeing the continuing development of AT, past 2.0! Best wishes, Boaz > On Aug 26, 2017, at 3:19 AM, Eugene Tan <Eug...@sy...> wrote: > > Big thanks for your dedication Boaz and the rest of the contributors for getting it here! I certainly feel there is some momentum starting to build here. The operators here are excited to see the python developments. > > Keep up all the good work everyone. > > > > Eugene > > Senior Physicist > Accelerator physics and operations group > Australian Synchrotron > > On 26 Aug. 2017, at 12:39 am, Boaz Nash <boa...@es... <mailto:boa...@es...>> wrote: > >> Dear all, >> >> Following with the timeline we’ve discussed, I went ahead and tagged the code in >> the at2devel SVN branch on SourceForge from today. This is AT 2.0. A zip file may be downloaded here: >> https://sourceforge.net/projects/atcollab/files/latest/download <https://sourceforge.net/projects/atcollab/files/latest/download> >> >> Please download this when you have a chance and give it a try. The demo files in atmat/atdemos should >> work. The integrators are compiled with atmexall as usual. >> >> I didn’t yet add an overall license file to the repository. Licensing the software should be agreed upon by the contributors. >> The suggestion by Will Rogers was to use the Apache Licence 2.0. If people have comments or other suggestions, let us know here >> on the mailing list, otherwise we will go ahead with this license. >> >> For continuing development, we will be migrating over to GitHub in the near future. As of now, the at2devel branch on SourceForge is no longer >> operational. Please don’t make any new commits to this repository. If we need to issue some bug fixes in the near future, we can >> create branches for this purpose to merge back into the trunk. >> >> Thanks to all who contributed to this release!! >> >> Best regards, >> Boaz >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org <http://slashdot.org/>! http://sdm.link/slashdot <http://sdm.link/slashdot>_______________________________________________ >> Atcollab-general mailing list >> Atc...@li... <mailto:Atc...@li...> >> https://lists.sourceforge.net/lists/listinfo/atcollab-general <https://lists.sourceforge.net/lists/listinfo/atcollab-general> |
|
From: Eugene T. <Eug...@sy...> - 2017-08-26 01:19:58
|
Big thanks for your dedication Boaz and the rest of the contributors for getting it here! I certainly feel there is some momentum starting to build here. The operators here are excited to see the python developments. Keep up all the good work everyone. Eugene Senior Physicist Accelerator physics and operations group Australian Synchrotron On 26 Aug. 2017, at 12:39 am, Boaz Nash <boa...@es...<mailto:boa...@es...>> wrote: Dear all, Following with the timeline we’ve discussed, I went ahead and tagged the code in the at2devel SVN branch on SourceForge from today. This is AT 2.0. A zip file may be downloaded here: https://sourceforge.net/projects/atcollab/files/latest/download Please download this when you have a chance and give it a try. The demo files in atmat/atdemos should work. The integrators are compiled with atmexall as usual. I didn’t yet add an overall license file to the repository. Licensing the software should be agreed upon by the contributors. The suggestion by Will Rogers was to use the Apache Licence 2.0. If people have comments or other suggestions, let us know here on the mailing list, otherwise we will go ahead with this license. For continuing development, we will be migrating over to GitHub in the near future. As of now, the at2devel branch on SourceForge is no longer operational. Please don’t make any new commits to this repository. If we need to issue some bug fixes in the near future, we can create branches for this purpose to merge back into the trunk. Thanks to all who contributed to this release!! Best regards, Boaz ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org<http://Slashdot.org>! http://sdm.link/slashdot _______________________________________________ Atcollab-general mailing list Atc...@li...<mailto:Atc...@li...> https://lists.sourceforge.net/lists/listinfo/atcollab-general |
|
From: Boaz N. <boa...@es...> - 2017-08-25 14:39:07
|
Dear all, Following with the timeline we’ve discussed, I went ahead and tagged the code in the at2devel SVN branch on SourceForge from today. This is AT 2.0. A zip file may be downloaded here: https://sourceforge.net/projects/atcollab/files/latest/download <https://sourceforge.net/projects/atcollab/files/latest/download> Please download this when you have a chance and give it a try. The demo files in atmat/atdemos should work. The integrators are compiled with atmexall as usual. I didn’t yet add an overall license file to the repository. Licensing the software should be agreed upon by the contributors. The suggestion by Will Rogers was to use the Apache Licence 2.0. If people have comments or other suggestions, let us know here on the mailing list, otherwise we will go ahead with this license. For continuing development, we will be migrating over to GitHub in the near future. As of now, the at2devel branch on SourceForge is no longer operational. Please don’t make any new commits to this repository. If we need to issue some bug fixes in the near future, we can create branches for this purpose to merge back into the trunk. Thanks to all who contributed to this release!! Best regards, Boaz |
|
From: NADOLSKI L. <lau...@sy...> - 2017-08-23 15:02:13
|
Thanks Laurent. It took me some time to locate the right files to modify. On my mac I do not have the file you mentioned. Nevertheless I have applied a similar patch in /Applications/MATLAB_R2016a.app/bin/maci64/mexopts I did successfully the modifications for these two files clang++_maci64.xml and clang_maci64.xml Thanks a lots ! Laurent. Dr Laurent S. NADOLSKI Coordinateur Exécutif des Accélérateurs Division Accélérateurs et Ingénierie, Synchrotron SOLEIL t: +33 (0)1 69 35 98 08 m: +33 (0)6 89 43 70 45 a: L'Orme des Merisiers Saint-Aubin BP 48, 91192 Gif-sur-Yvette CEDEX FRANCE w: www.synchrotron-soleil.fr<http://www.synchrotron-soleil.fr> e: nad...@sy...<mailto:nad...@sy...> Le 23 août 2017 à 14:04, Laurent Farvacque <lau...@es...<mailto:lau...@es...>> a écrit : Dear Laurent, You can easily have MATLAB R2016a compatible with MaxOSX Sierra (and R2015b also): The compile process is governed by the file $HOME/.matlab/R2016a/mex_C_maci64.xml You need to locate in this file all lines like: <dirExists name="$$/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk" /> and ADD just behind the line : <dirExists name="$$/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk" /> This makes make compatible with Xcode 8, and it works for all mex files I could try. The same should be done on the C++ file $HOME/.matlab/R2016a/mex_C++_maci64.xml Best regards, Laurent On 23 Aug 2017, at 13:42, NADOLSKI Laurent <lau...@sy...<mailto:lau...@sy...>> wrote: Dear Boaz, atsummary does not use lyap indeed (my mistake). I have gotten in trouble when I first used atx which is itself calling ohmienveloppe Now this is fine with moving the private directory. Compilation updated information : For information, I was able to recompile seamlessly AT under Matlab R2017a under MAC OS SIERRA 10.12.6 AT (mex) is not compatible on MAC OS SIERRA for R2016a as specified on Mathworks website. Error using mex No supported compiler or SDK was found. For options, visit http://www.mathworks.com/support/compilers/R2016a/maci64.html. Error in atmexall (line 34) eval(MEXCOMMAND); Best regards, Laurent. Dr Laurent S. NADOLSKI Coordinateur Exécutif des Accélérateurs Division Accélérateurs et Ingénierie, Synchrotron SOLEIL t: +33 (0)1 69 35 98 08 m: +33 (0)6 89 43 70 45 a: L'Orme des Merisiers Saint-Aubin BP 48, 91192 Gif-sur-Yvette CEDEX FRANCE w: www.synchrotron-soleil.fr<http://www.synchrotron-soleil.fr/> e: nad...@sy...<mailto:nad...@sy...> |
|
From: Laurent F. <lau...@es...> - 2017-08-23 12:04:37
|
Dear Laurent, You can easily have MATLAB R2016a compatible with MaxOSX Sierra (and R2015b also): The compile process is governed by the file $HOME/.matlab/R2016a/mex_C_maci64.xml You need to locate in this file all lines like: <dirExists name="$$/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk" /> and ADD just behind the line : <dirExists name="$$/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk" /> This makes make compatible with Xcode 8, and it works for all mex files I could try. The same should be done on the C++ file $HOME/.matlab/R2016a/mex_C++_maci64.xml Best regards, Laurent > On 23 Aug 2017, at 13:42, NADOLSKI Laurent <lau...@sy...> wrote: > Dear Boaz, > > atsummary does not use lyap indeed (my mistake). > I have gotten in trouble when I first used atx which is itself calling ohmienveloppe > Now this is fine with moving the private directory. > > Compilation updated information : > > For information, I was able to recompile seamlessly AT under Matlab R2017a under MAC OS SIERRA 10.12.6 > > AT (mex) is not compatible on MAC OS SIERRA for R2016a as specified on Mathworks website. > Error using mex > No supported compiler or SDK was found. For options, visit > http://www.mathworks.com/support/compilers/R2016a/maci64.html <http://www.mathworks.com/support/compilers/R2016a/maci64.html>. > Error in atmexall (line 34) > eval(MEXCOMMAND); > > Best regards, > > Laurent. > > > > > Dr Laurent S. NADOLSKI > Coordinateur Exécutif des Accélérateurs > Division Accélérateurs et Ingénierie, Synchrotron SOLEIL > t: +33 (0)1 69 35 98 08 m: +33 (0)6 89 43 70 45 > a: L'Orme des Merisiers Saint-Aubin BP 48, 91192 Gif-sur-Yvette CEDEX FRANCE > w: www.synchrotron-soleil.fr <http://www.synchrotron-soleil.fr/> e: nad...@sy... <mailto:nad...@sy...> |
|
From: NADOLSKI L. <lau...@sy...> - 2017-08-23 11:42:20
|
Dear Boaz, atsummary does not use lyap indeed (my mistake). I have gotten in trouble when I first used atx which is itself calling ohmienveloppe Now this is fine with moving the private directory. Compilation updated information : For information, I was able to recompile seamlessly AT under Matlab R2017a under MAC OS SIERRA 10.12.6 AT (mex) is not compatible on MAC OS SIERRA for R2016a as specified on Mathworks website. Error using mex No supported compiler or SDK was found. For options, visit http://www.mathworks.com/support/compilers/R2016a/maci64.html. Error in atmexall (line 34) eval(MEXCOMMAND); Best regards, Laurent. Dr Laurent S. NADOLSKI Coordinateur Exécutif des Accélérateurs Division Accélérateurs et Ingénierie, Synchrotron SOLEIL t: +33 (0)1 69 35 98 08 m: +33 (0)6 89 43 70 45 a: L'Orme des Merisiers Saint-Aubin BP 48, 91192 Gif-sur-Yvette CEDEX FRANCE w: www.synchrotron-soleil.fr<http://www.synchrotron-soleil.fr> e: nad...@sy...<mailto:nad...@sy...> Le 23 août 2017 à 11:46, Boaz Nash <boa...@es...<mailto:boa...@es...>> a écrit : Hello again, I should have written ‘addpath' instead of ‘setpath' in my email below. Boaz On Aug 23, 2017, at 11:39 AM, Boaz Nash <boa...@es...<mailto:boa...@es...>> wrote: Dear Laurent, Thanks for pointing out this issue with lyap. Indeed, it is needed by ohmienvelope which was moved. I moved private/lyap to the Radiation directory where ohmienvelope is now. It looks to me like atsummary does not use lyap, however. Could there be another reason why atsummary doesn’t work for you after the reorganization? Yes, re ohmienvelopedemo and in general, one needs to make sure machine_data and all the new directory structure is on the path. One can be sure of this by setting the path using a setpath(genpath(ATCOLLAB)) where ATCOLLAB is the top level directory. Best regards, Boaz On Aug 22, 2017, at 4:06 PM, NADOLSKI Laurent <lau...@sy...<mailto:lau...@sy...>> wrote: Dear Boaz, I have noticed that the reorganization of the file broke the function atsummary and ohmienvelope atcollab2017_branch/atmat/atphysics/ParameterSummaryFunctions/atsummary.m One solution could be to move also the private directory : private/lyap.m but ohmienvelope used it as well and is now located in another directory. So to avoid duplication, lyap should not be anymore a private function. ohmienvelopedemo does not work because spear2rad is not in the path anymore (now: machine_data/spear2rad.m) Undefined function or variable 'spear2rad'. Error in ohmienvelopedemo (line 3) A quick fix is to add machine_data to matlab the path Best regards, Laurent. Dr Laurent S. NADOLSKI Coordinateur Exécutif des Accélérateurs Division Accélérateurs et Ingénierie, Synchrotron SOLEIL t: +33 (0)1 69 35 98 08 m: +33 (0)6 89 43 70 45 a: L'Orme des Merisiers Saint-Aubin BP 48, 91192 Gif-sur-Yvette CEDEX FRANCE w: www.synchrotron-soleil.fr<http://www.synchrotron-soleil.fr> e: nad...@sy...<mailto:nad...@sy...> Le 28 juil. 2017 à 13:26, Boaz Nash <boa...@es...<mailto:boa...@es...>> a écrit : Dear all, After some discussion at ESRF, we decided to set August 25 as our date to finish AT2.0. There is always more to be done, but we will do what we can and call it finished at that time. The development is continuing in the at2devel branch in the subversion repository in SourceForge: https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/ As mentioned, following this release, we will look for a migration strategy to using git and hosting on github under the atcollab organization: https://github.com/atcollab At the moment, we are doing some cleaning and reorganization of some of the functions in the repository. In particular, some categories have been added to atphysics, and functions are being moved to relevant folders. https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/atmat/atphysics/ I may do something similar to the lattice directory https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/atmat/lattice/ I also created folders in the atdemos directory: https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/atmat/atdemos/ There were already some demos here originally by Andrei, but I’ve been adding some new ones. This is a big job, and I hope others will help test and improve these demos. One principle I am trying to follow is to only use lattice files in the machine_data directory: https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/machine_data/ These lattice files are still rather varied- some use AT 1.2 style with global variables for the lattice creation, some may include RF cavities and others not. I hope we can use this directory to standardize on what we consider best practice for lattice files. Then if we make sure that all the demos in the atdemos directory run properly, we can be confident that a good amount of AT works properly with these lattice files. Glad to hear comments and get input or help before we release AT2.0. Best regards, Boaz ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ Atcollab-general mailing list Atc...@li... https://lists.sourceforge.net/lists/listinfo/atcollab-general |
|
From: Boaz N. <boa...@es...> - 2017-08-23 09:46:38
|
Hello again, I should have written ‘addpath' instead of ‘setpath' in my email below. Boaz > On Aug 23, 2017, at 11:39 AM, Boaz Nash <boa...@es...> wrote: > > Dear Laurent, > > Thanks for pointing out this issue with lyap. Indeed, it is needed by ohmienvelope which was moved. > I moved private/lyap to the Radiation directory where ohmienvelope is now. It looks to me like atsummary does not use lyap, however. > Could there be another reason why atsummary doesn’t work for you after the reorganization? > > Yes, re ohmienvelopedemo and in general, one needs to make sure machine_data and all the new directory structure is on the path. > One can be sure of this by setting the path using a setpath(genpath(ATCOLLAB)) where ATCOLLAB is the top level directory. > > Best regards, > Boaz > >> On Aug 22, 2017, at 4:06 PM, NADOLSKI Laurent <lau...@sy...> wrote: >> >> Dear Boaz, >> >> I have noticed that the reorganization of the file broke the function atsummary and ohmienvelope >> atcollab2017_branch/atmat/atphysics/ParameterSummaryFunctions/atsummary.m >> One solution could be to move also the private directory : private/lyap.m >> >> but ohmienvelope used it as well and is now located in another directory. >> So to avoid duplication, lyap should not be anymore a private function. >> >> ohmienvelopedemo does not work because spear2rad is not in the path anymore (now: machine_data/spear2rad.m) >> Undefined function or variable 'spear2rad'. >> Error in ohmienvelopedemo (line 3) >> >> A quick fix is to add machine_data to matlab the path >> >> Best regards, >> >> Laurent. >> >> >> Dr Laurent S. NADOLSKI >> Coordinateur Exécutif des Accélérateurs >> Division Accélérateurs et Ingénierie, Synchrotron SOLEIL >> t: +33 (0)1 69 35 98 08 m: +33 (0)6 89 43 70 45 >> a: L'Orme des Merisiers Saint-Aubin BP 48, 91192 Gif-sur-Yvette CEDEX FRANCE >> w: www.synchrotron-soleil.fr e: nad...@sy... >> >>> Le 28 juil. 2017 à 13:26, Boaz Nash <boa...@es...> a écrit : >>> >>> Dear all, >>> >>> After some discussion at ESRF, we decided to set August 25 as our date to finish AT2.0. >>> There is always more to be done, but we will do what we can and call it finished at that time. >>> The development is continuing in the at2devel branch in the subversion repository in SourceForge: >>> https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/ >>> >>> As mentioned, following this release, we will look for a migration strategy to using git and hosting >>> on github under the atcollab organization: >>> https://github.com/atcollab >>> >>> At the moment, we are doing some cleaning and reorganization of some of the functions in the repository. >>> In particular, some categories have been added to atphysics, and functions are being moved to relevant folders. >>> https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/atmat/atphysics/ >>> >>> I may do something similar to the lattice directory >>> https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/atmat/lattice/ >>> >>> I also created folders in the atdemos directory: >>> https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/atmat/atdemos/ >>> >>> There were already some demos here originally by Andrei, but I’ve been adding some new ones. >>> This is a big job, and I hope others will help test and improve these demos. >>> One principle I am trying to follow is to only use lattice files in the machine_data directory: >>> https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/machine_data/ >>> These lattice files are still rather varied- some use AT 1.2 style with global variables for the lattice >>> creation, some may include RF cavities and others not. I hope we can use this directory to standardize on >>> what we consider best practice for lattice files. Then if we make sure that all the demos in the atdemos directory >>> run properly, we can be confident that a good amount of AT works properly with these lattice files. >>> >>> Glad to hear comments and get input or help before we release AT2.0. >>> >>> Best regards, >>> Boaz >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ >>> Atcollab-general mailing list >>> Atc...@li... >>> https://lists.sourceforge.net/lists/listinfo/atcollab-general >> > |
|
From: Boaz N. <boa...@es...> - 2017-08-23 09:39:33
|
Dear Laurent, Thanks for pointing out this issue with lyap. Indeed, it is needed by ohmienvelope which was moved. I moved private/lyap to the Radiation directory where ohmienvelope is now. It looks to me like atsummary does not use lyap, however. Could there be another reason why atsummary doesn’t work for you after the reorganization? Yes, re ohmienvelopedemo and in general, one needs to make sure machine_data and all the new directory structure is on the path. One can be sure of this by setting the path using a setpath(genpath(ATCOLLAB)) where ATCOLLAB is the top level directory. Best regards, Boaz > On Aug 22, 2017, at 4:06 PM, NADOLSKI Laurent <lau...@sy...> wrote: > > Dear Boaz, > > I have noticed that the reorganization of the file broke the function atsummary and ohmienvelope > atcollab2017_branch/atmat/atphysics/ParameterSummaryFunctions/atsummary.m > One solution could be to move also the private directory : private/lyap.m > > but ohmienvelope used it as well and is now located in another directory. > So to avoid duplication, lyap should not be anymore a private function. > > ohmienvelopedemo does not work because spear2rad is not in the path anymore (now: machine_data/spear2rad.m) > Undefined function or variable 'spear2rad'. > Error in ohmienvelopedemo (line 3) > > A quick fix is to add machine_data to matlab the path > > Best regards, > > Laurent. > > > Dr Laurent S. NADOLSKI > Coordinateur Exécutif des Accélérateurs > Division Accélérateurs et Ingénierie, Synchrotron SOLEIL > t: +33 (0)1 69 35 98 08 m: +33 (0)6 89 43 70 45 > a: L'Orme des Merisiers Saint-Aubin BP 48, 91192 Gif-sur-Yvette CEDEX FRANCE > w: www.synchrotron-soleil.fr e: nad...@sy... > >> Le 28 juil. 2017 à 13:26, Boaz Nash <boa...@es...> a écrit : >> >> Dear all, >> >> After some discussion at ESRF, we decided to set August 25 as our date to finish AT2.0. >> There is always more to be done, but we will do what we can and call it finished at that time. >> The development is continuing in the at2devel branch in the subversion repository in SourceForge: >> https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/ >> >> As mentioned, following this release, we will look for a migration strategy to using git and hosting >> on github under the atcollab organization: >> https://github.com/atcollab >> >> At the moment, we are doing some cleaning and reorganization of some of the functions in the repository. >> In particular, some categories have been added to atphysics, and functions are being moved to relevant folders. >> https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/atmat/atphysics/ >> >> I may do something similar to the lattice directory >> https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/atmat/lattice/ >> >> I also created folders in the atdemos directory: >> https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/atmat/atdemos/ >> >> There were already some demos here originally by Andrei, but I’ve been adding some new ones. >> This is a big job, and I hope others will help test and improve these demos. >> One principle I am trying to follow is to only use lattice files in the machine_data directory: >> https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/machine_data/ >> These lattice files are still rather varied- some use AT 1.2 style with global variables for the lattice >> creation, some may include RF cavities and others not. I hope we can use this directory to standardize on >> what we consider best practice for lattice files. Then if we make sure that all the demos in the atdemos directory >> run properly, we can be confident that a good amount of AT works properly with these lattice files. >> >> Glad to hear comments and get input or help before we release AT2.0. >> >> Best regards, >> Boaz >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ >> Atcollab-general mailing list >> Atc...@li... >> https://lists.sourceforge.net/lists/listinfo/atcollab-general > |
|
From: NADOLSKI L. <lau...@sy...> - 2017-08-22 14:06:35
|
Dear Boaz, I have noticed that the reorganization of the file broke the function atsummary and ohmienvelope atcollab2017_branch/atmat/atphysics/ParameterSummaryFunctions/atsummary.m One solution could be to move also the private directory : private/lyap.m but ohmienvelope used it as well and is now located in another directory. So to avoid duplication, lyap should not be anymore a private function. ohmienvelopedemo does not work because spear2rad is not in the path anymore (now: machine_data/spear2rad.m) Undefined function or variable 'spear2rad'. Error in ohmienvelopedemo (line 3) A quick fix is to add machine_data to matlab the path Best regards, Laurent. Dr Laurent S. NADOLSKI Coordinateur Exécutif des Accélérateurs Division Accélérateurs et Ingénierie, Synchrotron SOLEIL t: +33 (0)1 69 35 98 08 m: +33 (0)6 89 43 70 45 a: L'Orme des Merisiers Saint-Aubin BP 48, 91192 Gif-sur-Yvette CEDEX FRANCE w: www.synchrotron-soleil.fr<http://www.synchrotron-soleil.fr> e: nad...@sy...<mailto:nad...@sy...> Le 28 juil. 2017 à 13:26, Boaz Nash <boa...@es...<mailto:boa...@es...>> a écrit : Dear all, After some discussion at ESRF, we decided to set August 25 as our date to finish AT2.0. There is always more to be done, but we will do what we can and call it finished at that time. The development is continuing in the at2devel branch in the subversion repository in SourceForge: https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/ As mentioned, following this release, we will look for a migration strategy to using git and hosting on github under the atcollab organization: https://github.com/atcollab At the moment, we are doing some cleaning and reorganization of some of the functions in the repository. In particular, some categories have been added to atphysics, and functions are being moved to relevant folders. https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/atmat/atphysics/ I may do something similar to the lattice directory https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/atmat/lattice/ I also created folders in the atdemos directory: https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/atmat/atdemos/ There were already some demos here originally by Andrei, but I’ve been adding some new ones. This is a big job, and I hope others will help test and improve these demos. One principle I am trying to follow is to only use lattice files in the machine_data directory: https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/machine_data/ These lattice files are still rather varied- some use AT 1.2 style with global variables for the lattice creation, some may include RF cavities and others not. I hope we can use this directory to standardize on what we consider best practice for lattice files. Then if we make sure that all the demos in the atdemos directory run properly, we can be confident that a good amount of AT works properly with these lattice files. Glad to hear comments and get input or help before we release AT2.0. Best regards, Boaz ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org<http://Slashdot.org>! http://sdm.link/slashdot_______________________________________________ Atcollab-general mailing list Atc...@li...<mailto:Atc...@li...> https://lists.sourceforge.net/lists/listinfo/atcollab-general |
|
From: NADOLSKI L. <lau...@sy...> - 2017-08-22 14:04:33
|
Dear all, On my side, everything works smoothly to till (including) Matlab R2016a. I did not have time yet to investigate the issue of the newest versions of Matlab. Best regards, Laurent. Dr Laurent S. NADOLSKI Coordinateur Exécutif des Accélérateurs Division Accélérateurs et Ingénierie, Synchrotron SOLEIL t: +33 (0)1 69 35 98 08 m: +33 (0)6 89 43 70 45 a: L'Orme des Merisiers Saint-Aubin BP 48, 91192 Gif-sur-Yvette CEDEX FRANCE w: www.synchrotron-soleil.fr<http://www.synchrotron-soleil.fr> e: nad...@sy...<mailto:nad...@sy...> Le 1 août 2017 à 11:14, Eugene Tan <Eug...@sy...<mailto:Eug...@sy...>> a écrit : I just checked the symbols in the compiled files using nm and they do not contain the global symbols for passFunction or trackFunction, only local. Matlab has changed the way it MEXs again. Matlab2016a [opi@CR01OPI05 ~]$ cd /usr/local/MATLAB/R2016a/extern/lib/glnxa64/ fexport.map mexFunction.map Matlab2017a user@asci: /usr/local/MATLAB/R2017a ls extern/lib/glnxa64/ c_exportsmexfileversion.map fexport.map fortran_exportsmexfileversion.map mexFunction.map It now has a two layer approach with LINKEXPORT(mexFunction.map) followed by LINKEXPORTVER (c_exportsmexfileversion.map). So what works for me is to make some small changes to the *.map file and mexpassmethod.m (attached). The change appears to have happened in R2016b! Some nitty gritty detail below if you’re interested. Can people also check that these changes don’t break anything before I commit this change to AT2.0? I don’t know how to push this out to AT1.4, so if it works can someone please do this? Eugene >> !nm /user/home/at14/atintegrators/AperturePass.mexa64 0000000000000b0c t AperturePass 0000000000000ac5 t atGetDoubleArray 0000000000202090 b __bss_start 0000000000202090 b completed.6344 w __cxa_finalize@@GLIBC_2.2.5 00000000000009e0 t deregister_tm_clones 0000000000000a50 t __do_global_dtors_aux 0000000000201d80 t __do_global_dtors_aux_fini_array_entry 0000000000201d90 d __dso_handle 0000000000201d98 d _DYNAMIC 0000000000202090 d _edata 0000000000202098 b _end 0000000000000d04 t _fini 0000000000000a90 t frame_dummy 0000000000201d78 t __frame_dummy_init_array_entry 0000000000000ed0 r __FRAME_END__ 0000000000202000 d _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 00000000000008c0 t _init w _ITM_deregisterTMCloneTable w _ITM_registerTMCloneTable 0000000000201d88 d __JCR_END__ 0000000000201d88 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000000000 A MEX U mexErrMsgIdAndTxt 0000000000000cf1 T mexfilerequiredapiversion 0000000000000bfc T mexFunction U mexMakeMemoryPersistent U mxCreateCellMatrix@@v7.3 U mxCreateString U mxDuplicateArray U mxGetField@@v7.3 U mxGetInf U mxGetM U mxGetN U mxGetPr U mxIsNaN U mxMalloc U mxSetCell@@v7.3 0000000000000a10 t register_tm_clones 0000000000202090 d __TMC_END__ 0000000000000ba2 t trackFunction (small t means local) >> !nm /user/home/at14/atintegrators/AperturePass.mexa64 0000000000000b3c t AperturePass 0000000000000af5 t atGetDoubleArray 0000000000202090 b __bss_start 0000000000202090 b completed.6344 w __cxa_finalize@@GLIBC_2.2.5 0000000000000a10 t deregister_tm_clones 0000000000000a80 t __do_global_dtors_aux 0000000000201d80 t __do_global_dtors_aux_fini_array_entry 0000000000201d90 d __dso_handle 0000000000201d98 d _DYNAMIC 0000000000202090 d _edata 0000000000202098 b _end 0000000000000d34 t _fini 0000000000000ac0 t frame_dummy 0000000000201d78 t __frame_dummy_init_array_entry 0000000000000f00 r __FRAME_END__ 0000000000202000 d _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 00000000000008f0 t _init w _ITM_deregisterTMCloneTable w _ITM_registerTMCloneTable 0000000000201d88 d __JCR_END__ 0000000000201d88 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000000000 A MEX U mexErrMsgIdAndTxt 0000000000000d21 T mexfilerequiredapiversion 0000000000000c2c T mexFunction U mexMakeMemoryPersistent U mxCreateCellMatrix@@v7.3 U mxCreateString U mxDuplicateArray U mxGetField@@v7.3 U mxGetInf U mxGetM U mxGetN U mxGetPr U mxIsNaN U mxMalloc U mxSetCell@@v7.3 0000000000000a40 t register_tm_clones 0000000000202090 d __TMC_END__ 0000000000000bd2 T trackFunction (capital T means global) Matlab2016a: LINKEXPORT="-Wl,--version-script,"$MATLABROOT/extern/lib/$ARCH/mexFunction.map"" LDFLAGS="$LDFLAGS $LDTYPE $LINKLIBS $LINKEXPORT" Matlab2017a: FUNCTIONMAP=""$MATLABROOT/extern/lib/$ARCH/mexFunction.map"" VERSIONMAP=""$MATLABROOT/extern/lib/$ARCH/c_exportsmexfileversion.map"" LINKEXPORT="-Wl,--version-script,$FUNCTIONMAP" LINKEXPORTVER="-Wl,--version-script,$VERSIONMAP" LDFLAGS="-pthread -Wl,--no-undefined -Wl,-rpath-link,$MATLABROOT/bin/$ARCH" LDFLAGS="$LDFLAGS $LDTYPE $LINKLIBS $LINKEXPORT" CMDLINE2="$LD $LDFLAGS $LDTYPE $LINKOPTIM $LINKEXPORTVER $OBJS $CLIBS $LINKLIBS -o $EXE" From: Zeus Martí [mailto:ze...@ce...] Sent: Tuesday, August 01, 2017 3:47 PM To: atc...@li...<mailto:atc...@li...> Subject: Re: [Atcollab-general] help with AT error Hi there, We just noticed yesterday some similar problems with a similar configuration "CentOS7 + Matlab2017a + AT1.3". AT1.4 also fails, but AT1.3 has the wonderful ability to crash Matlab2017a every time it is executed. It has been recently updated, the previous version was "CentOS7 + Matlab2015a + AT1.3", so far we workaround using the old release. In our case, the same files are used by different machines with different Matlab versions so we decided not to recompile yet. Eugene, do you by any chance know if the recompiled files work in earlier versions? Best regards, Zeus On 01/08/2017 5:07, Eugene Tan wrote: We have been trying to get AT running on CentOS7 + Matlab2017a + AT1.4 and comes up with: Error using atpass Element # 0: Library file: /usr/home/at14/atintegrators/AperturePass.mexa64, No passFunction or trackFunction available I’ve recompiles all the pass methods using “atmexall” and compiles successfully. Has anyone had this problem before? Windows + Matlab2016a + AT2.0 is OK. Eugene ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org<http://slashdot.org/>! http://sdm.link/slashdot _______________________________________________ Atcollab-general mailing list Atc...@li...<mailto:Atc...@li...> https://lists.sourceforge.net/lists/listinfo/atcollab-general <mexFunctionGLNX86.map><mexpassmethod.m>------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org<http://slashdot.org/>! http://sdm.link/slashdot_______________________________________________ Atcollab-general mailing list Atc...@li...<mailto:Atc...@li...> https://lists.sourceforge.net/lists/listinfo/atcollab-general |
|
From: Eugene T. <Eug...@sy...> - 2017-08-18 01:40:57
|
Its been a while so I don't know if its still valid. These were some of my notes that I took to compile plotfamily many years ago. Hope this helps.
The following is a documentation of the steps taken and the problems encountered:
1) The compile script was given by Greg Portmann and is relatively simple (below).
eval(['mcc -mv -a Tada.wav -a Chord.wav -a UtopiaQuestion.wav -a UtopiaError.wav -a Ap
erturePass -a BndMPoleSymplectic4Pass -a BndMPoleSymplectic4RadPass -a CavityPass -a C
orrectorPass -a DriftPass -a EAperturePass -a IdentityPass -a Matrix66Pass -a QuadLine
arPass -a SolenoidLinearPass -a StrMPoleSymplectic4Pass -a StrMPoleSymplectic4RadPass
-a ThinMPolePass -a findmpoleraddiffmatrix -a StrCorrMPoleSymplectic4RadPass -a StrCor
rMPoleSymplectic4Pass ',ApplicationName]);
2) First problem was that it needed the MCR directory (Matlab Runtime files). I tried to use the scripts that Greg provided that uses the locally installed Matlab runtime files however it didn't work (STILL NEEDS TO BE LOOKED AT WITH GREG). I was able to generate the MCR files using BUILDMCR to create a MCRInstaller.zip. This was extracted into a temporary directory. To run the compiled plotfamily you need to run "./run_plotfamily.sh <mcr dir>" shell script that is generated at compile time.
3) It complained that it couldn't find and load B_vs_I_data.mat. The reason was the it was defined with relative paths. Better solution is to always define absolute:
load(fullfile(getmmlroot,'machine','ASP','StorageRing','magnet_calibration_curves','B_vs_I_data.mat'));
4) It then complained about not being able to find StrCorrMPoleSymplectic4RadPass. The first thing I did was try to add it to the search path using ADDPATH, however this is not permitted when running in standalone mode. The way the compiler works is to recursively follow the all the links within the program that you want to compile however if you call C programs that then also call other libraries, these libraries need to be linked. Hence you need to add the extra parameter "-a StrCorrMPoleSymplectic4RadPass" when calling MCC.
5) Plotfamily automatically checks if the AO is loaded and if not will call AOINIT.
6) After fixing the above problems it seemed to load fine with MCA as the comms. The GUI came out however when trying to retrieve data it couldn't find the EPICS libraries. After compiling, MCC will generate a run_plotfamily.sh file that is a script that gets things going and in that file you need to define the necessary ENV variables. So you have to add the /asp/ics/common/epics/base/lib/linux-x86/ to LD_LIBRARY_PATH. And for good measure also added /asp/ics/common/epics/base/bin/linux-x86/ to PATH.
7) After adding the library path it seemed to then run but then returned with an Out Of Memory error and crashed when I closed plotfamily.
8) Next was to try it with LabCA instead. The complication was that OPI05 where the compiler was installed was a 64 bit machine and didn't have the new LabCA files and had to modify setpathmml to add the new _64 option. The new LabCA distribution comes precompiled for 64bit.
9) Realised that the compiled program will use whatever comms is originally defined in the session when the compiler was called. EG "setpathasp mca; cc;" will compile and use only MCA, while "setpathasp labca; cc;" will use LabCA.
10) With LabCA, like MCA I had to add the library path /asp/usr/middleLayer/links/labca_new/lib/l
inux-x86_64 to LD_LIBRARY_PATH. Note that "labca_new" is only a temporary directory and will eventually be merged with the nominal directory "labca".
11) Before compiling I had to move the *.m files in /asp/usr/middleLayer/links/labca_new/bin/l
inux-x86_64/labca/ into another folder because the *.m files would shadow the *.mexa64 files and cause compile problems.
WOHO Compiled and running plotfamily. All the applications under "Common Tasks" also work (not extensively tested yet).
Unfortunately this only runs on OPI05 because its the only one with the new Matlab and associated compiler. Reason being the GLIBC version has been updated on OPI05 while OPI01-OPI04 and PHY01 haven't and therefore can't use the new Matlab and compiler.
Error running on PHY01:
Fatal error loading library /asp/usr/temp/ASPcompile/ASP/compile/v76/bin/glnxa64/libmx.so Error: /lib64/tls/libc.so.6: version `GLIBC_2.3.4' not found (required by /asp/usr/temp/ASPcompile/ASP/compile/v76/bin/glnxa64/libut.so)
Error running on OPI01:
./run_plotfamily.sh: line 42: ./plotfamily: cannot execute binary file
-----Original Message-----
From: Corbett, Jeff [mailto:co...@sl...]
Sent: Friday, August 18, 2017 10:14 AM
To: Eugene Tan; Zeus Martí
Cc: atc...@li...
Subject: compiling labca into matlab
Hi, all,
We are trying to use the matlab compiler to compile m-files that contain lcaGet and lcaPut calls to create executable files on windows.
Does anyone know the correct >>mcc command?
Thanks, Jeff
-----Original Message-----
From: Eugene Tan [mailto:Eug...@sy...]
Sent: Tuesday, August 01, 2017 2:14 AM
To: Zeus Martí
Cc: atc...@li...
Subject: Re: [Atcollab-general] help with AT error
I just checked the symbols in the compiled files using nm and they do not contain the global symbols for passFunction or trackFunction, only local. Matlab has changed the way it MEXs again.
Matlab2016a
[opi@CR01OPI05 ~]$ cd /usr/local/MATLAB/R2016a/extern/lib/glnxa64/
fexport.map mexFunction.map
Matlab2017a
user@asci: /usr/local/MATLAB/R2017a ls extern/lib/glnxa64/
c_exportsmexfileversion.map fexport.map fortran_exportsmexfileversion.map mexFunction.map
It now has a two layer approach with LINKEXPORT(mexFunction.map) followed by LINKEXPORTVER (c_exportsmexfileversion.map). So what works for me is to make some small changes to the *.map file and mexpassmethod.m (attached). The change appears to have happened in R2016b!
Some nitty gritty detail below if you're interested.
Can people also check that these changes don't break anything before I commit this change to AT2.0?
I don't know how to push this out to AT1.4, so if it works can someone please do this?
Eugene
>> !nm /user/home/at14/atintegrators/AperturePass.mexa64
0000000000000b0c t AperturePass
0000000000000ac5 t atGetDoubleArray
0000000000202090 b __bss_start
0000000000202090 b completed.6344
w __cxa_finalize@@GLIBC_2.2.5
00000000000009e0 t deregister_tm_clones
0000000000000a50 t __do_global_dtors_aux
0000000000201d80 t __do_global_dtors_aux_fini_array_entry
0000000000201d90 d __dso_handle
0000000000201d98 d _DYNAMIC
0000000000202090 d _edata
0000000000202098 b _end
0000000000000d04 t _fini
0000000000000a90 t frame_dummy
0000000000201d78 t __frame_dummy_init_array_entry
0000000000000ed0 r __FRAME_END__
0000000000202000 d _GLOBAL_OFFSET_TABLE_
w __gmon_start__
00000000000008c0 t _init
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
0000000000201d88 d __JCR_END__
0000000000201d88 d __JCR_LIST__
w _Jv_RegisterClasses
0000000000000000 A MEX
U mexErrMsgIdAndTxt
0000000000000cf1 T mexfilerequiredapiversion
0000000000000bfc T mexFunction
U mexMakeMemoryPersistent
U mxCreateCellMatrix@@v7.3
U mxCreateString
U mxDuplicateArray
U mxGetField@@v7.3
U mxGetInf
U mxGetM
U mxGetN
U mxGetPr
U mxIsNaN
U mxMalloc
U mxSetCell@@v7.3
0000000000000a10 t register_tm_clones
0000000000202090 d __TMC_END__
0000000000000ba2 t trackFunction
(small t means local)
>> !nm /user/home/at14/atintegrators/AperturePass.mexa64
0000000000000b3c t AperturePass
0000000000000af5 t atGetDoubleArray
0000000000202090 b __bss_start
0000000000202090 b completed.6344
w __cxa_finalize@@GLIBC_2.2.5
0000000000000a10 t deregister_tm_clones
0000000000000a80 t __do_global_dtors_aux
0000000000201d80 t __do_global_dtors_aux_fini_array_entry
0000000000201d90 d __dso_handle
0000000000201d98 d _DYNAMIC
0000000000202090 d _edata
0000000000202098 b _end
0000000000000d34 t _fini
0000000000000ac0 t frame_dummy
0000000000201d78 t __frame_dummy_init_array_entry
0000000000000f00 r __FRAME_END__
0000000000202000 d _GLOBAL_OFFSET_TABLE_
w __gmon_start__
00000000000008f0 t _init
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
0000000000201d88 d __JCR_END__
0000000000201d88 d __JCR_LIST__
w _Jv_RegisterClasses
0000000000000000 A MEX
U mexErrMsgIdAndTxt
0000000000000d21 T mexfilerequiredapiversion
0000000000000c2c T mexFunction
U mexMakeMemoryPersistent
U mxCreateCellMatrix@@v7.3
U mxCreateString
U mxDuplicateArray
U mxGetField@@v7.3
U mxGetInf
U mxGetM
U mxGetN
U mxGetPr
U mxIsNaN
U mxMalloc
U mxSetCell@@v7.3
0000000000000a40 t register_tm_clones
0000000000202090 d __TMC_END__
0000000000000bd2 T trackFunction
(capital T means global)
Matlab2016a:
LINKEXPORT="-Wl,--version-script,"$MATLABROOT/extern/lib/$ARCH/mexFunction.map""
LDFLAGS="$LDFLAGS $LDTYPE $LINKLIBS $LINKEXPORT"
Matlab2017a:
FUNCTIONMAP=""$MATLABROOT/extern/lib/$ARCH/mexFunction.map""
VERSIONMAP=""$MATLABROOT/extern/lib/$ARCH/c_exportsmexfileversion.map""
LINKEXPORT="-Wl,--version-script,$FUNCTIONMAP"
LINKEXPORTVER="-Wl,--version-script,$VERSIONMAP"
LDFLAGS="-pthread -Wl,--no-undefined -Wl,-rpath-link,$MATLABROOT/bin/$ARCH"
LDFLAGS="$LDFLAGS $LDTYPE $LINKLIBS $LINKEXPORT"
CMDLINE2="$LD $LDFLAGS $LDTYPE $LINKOPTIM $LINKEXPORTVER $OBJS $CLIBS $LINKLIBS -o $EXE"
From: Zeus Martí [mailto:ze...@ce...]
Sent: Tuesday, August 01, 2017 3:47 PM
To: atc...@li...
Subject: Re: [Atcollab-general] help with AT error
Hi there,
We just noticed yesterday some similar problems with a similar configuration "CentOS7 + Matlab2017a + AT1.3". AT1.4 also fails, but AT1.3 has the wonderful ability to crash Matlab2017a every time it is executed. It has been recently updated, the previous version was "CentOS7 + Matlab2015a + AT1.3", so far we workaround using the old release. In our case, the same files are used by different machines with different Matlab versions so we decided not to recompile yet.
Eugene, do you by any chance know if the recompiled files work in earlier versions?
Best regards,
Zeus
On 01/08/2017 5:07, Eugene Tan wrote:
We have been trying to get AT running on CentOS7 + Matlab2017a + AT1.4 and comes up with:
Error using atpass
Element # 0: Library file: /usr/home/at14/atintegrators/AperturePass.mexa64, No passFunction or trackFunction available
I've recompiles all the pass methods using "atmexall" and compiles successfully.
Has anyone had this problem before? Windows + Matlab2016a + AT2.0 is OK.
Eugene
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Atcollab-general mailing list
Atc...@li...
https://lists.sourceforge.net/lists/listinfo/atcollab-general
|
|
From: Corbett, J. <co...@sl...> - 2017-08-18 00:13:44
|
Hi, all,
We are trying to use the matlab compiler to compile m-files that contain lcaGet and lcaPut calls to create executable files on windows.
Does anyone know the correct >>mcc command?
Thanks, Jeff
-----Original Message-----
From: Eugene Tan [mailto:Eug...@sy...]
Sent: Tuesday, August 01, 2017 2:14 AM
To: Zeus Martí
Cc: atc...@li...
Subject: Re: [Atcollab-general] help with AT error
I just checked the symbols in the compiled files using nm and they do not contain the global symbols for passFunction or trackFunction, only local. Matlab has changed the way it MEXs again.
Matlab2016a
[opi@CR01OPI05 ~]$ cd /usr/local/MATLAB/R2016a/extern/lib/glnxa64/
fexport.map mexFunction.map
Matlab2017a
user@asci: /usr/local/MATLAB/R2017a ls extern/lib/glnxa64/
c_exportsmexfileversion.map fexport.map fortran_exportsmexfileversion.map mexFunction.map
It now has a two layer approach with LINKEXPORT(mexFunction.map) followed by LINKEXPORTVER (c_exportsmexfileversion.map). So what works for me is to make some small changes to the *.map file and mexpassmethod.m (attached). The change appears to have happened in R2016b!
Some nitty gritty detail below if you're interested.
Can people also check that these changes don't break anything before I commit this change to AT2.0?
I don't know how to push this out to AT1.4, so if it works can someone please do this?
Eugene
>> !nm /user/home/at14/atintegrators/AperturePass.mexa64
0000000000000b0c t AperturePass
0000000000000ac5 t atGetDoubleArray
0000000000202090 b __bss_start
0000000000202090 b completed.6344
w __cxa_finalize@@GLIBC_2.2.5
00000000000009e0 t deregister_tm_clones
0000000000000a50 t __do_global_dtors_aux
0000000000201d80 t __do_global_dtors_aux_fini_array_entry
0000000000201d90 d __dso_handle
0000000000201d98 d _DYNAMIC
0000000000202090 d _edata
0000000000202098 b _end
0000000000000d04 t _fini
0000000000000a90 t frame_dummy
0000000000201d78 t __frame_dummy_init_array_entry
0000000000000ed0 r __FRAME_END__
0000000000202000 d _GLOBAL_OFFSET_TABLE_
w __gmon_start__
00000000000008c0 t _init
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
0000000000201d88 d __JCR_END__
0000000000201d88 d __JCR_LIST__
w _Jv_RegisterClasses
0000000000000000 A MEX
U mexErrMsgIdAndTxt
0000000000000cf1 T mexfilerequiredapiversion
0000000000000bfc T mexFunction
U mexMakeMemoryPersistent
U mxCreateCellMatrix@@v7.3
U mxCreateString
U mxDuplicateArray
U mxGetField@@v7.3
U mxGetInf
U mxGetM
U mxGetN
U mxGetPr
U mxIsNaN
U mxMalloc
U mxSetCell@@v7.3
0000000000000a10 t register_tm_clones
0000000000202090 d __TMC_END__
0000000000000ba2 t trackFunction
(small t means local)
>> !nm /user/home/at14/atintegrators/AperturePass.mexa64
0000000000000b3c t AperturePass
0000000000000af5 t atGetDoubleArray
0000000000202090 b __bss_start
0000000000202090 b completed.6344
w __cxa_finalize@@GLIBC_2.2.5
0000000000000a10 t deregister_tm_clones
0000000000000a80 t __do_global_dtors_aux
0000000000201d80 t __do_global_dtors_aux_fini_array_entry
0000000000201d90 d __dso_handle
0000000000201d98 d _DYNAMIC
0000000000202090 d _edata
0000000000202098 b _end
0000000000000d34 t _fini
0000000000000ac0 t frame_dummy
0000000000201d78 t __frame_dummy_init_array_entry
0000000000000f00 r __FRAME_END__
0000000000202000 d _GLOBAL_OFFSET_TABLE_
w __gmon_start__
00000000000008f0 t _init
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
0000000000201d88 d __JCR_END__
0000000000201d88 d __JCR_LIST__
w _Jv_RegisterClasses
0000000000000000 A MEX
U mexErrMsgIdAndTxt
0000000000000d21 T mexfilerequiredapiversion
0000000000000c2c T mexFunction
U mexMakeMemoryPersistent
U mxCreateCellMatrix@@v7.3
U mxCreateString
U mxDuplicateArray
U mxGetField@@v7.3
U mxGetInf
U mxGetM
U mxGetN
U mxGetPr
U mxIsNaN
U mxMalloc
U mxSetCell@@v7.3
0000000000000a40 t register_tm_clones
0000000000202090 d __TMC_END__
0000000000000bd2 T trackFunction
(capital T means global)
Matlab2016a:
LINKEXPORT="-Wl,--version-script,"$MATLABROOT/extern/lib/$ARCH/mexFunction.map""
LDFLAGS="$LDFLAGS $LDTYPE $LINKLIBS $LINKEXPORT"
Matlab2017a:
FUNCTIONMAP=""$MATLABROOT/extern/lib/$ARCH/mexFunction.map""
VERSIONMAP=""$MATLABROOT/extern/lib/$ARCH/c_exportsmexfileversion.map""
LINKEXPORT="-Wl,--version-script,$FUNCTIONMAP"
LINKEXPORTVER="-Wl,--version-script,$VERSIONMAP"
LDFLAGS="-pthread -Wl,--no-undefined -Wl,-rpath-link,$MATLABROOT/bin/$ARCH"
LDFLAGS="$LDFLAGS $LDTYPE $LINKLIBS $LINKEXPORT"
CMDLINE2="$LD $LDFLAGS $LDTYPE $LINKOPTIM $LINKEXPORTVER $OBJS $CLIBS $LINKLIBS -o $EXE"
From: Zeus Martí [mailto:ze...@ce...]
Sent: Tuesday, August 01, 2017 3:47 PM
To: atc...@li...
Subject: Re: [Atcollab-general] help with AT error
Hi there,
We just noticed yesterday some similar problems with a similar configuration "CentOS7 + Matlab2017a + AT1.3". AT1.4 also fails, but AT1.3 has the wonderful ability to crash Matlab2017a every time it is executed. It has been recently updated, the previous version was "CentOS7 + Matlab2015a + AT1.3", so far we workaround using the old release. In our case, the same files are used by different machines with different Matlab versions so we decided not to recompile yet.
Eugene, do you by any chance know if the recompiled files work in earlier versions?
Best regards,
Zeus
On 01/08/2017 5:07, Eugene Tan wrote:
We have been trying to get AT running on CentOS7 + Matlab2017a + AT1.4 and comes up with:
Error using atpass
Element # 0: Library file: /usr/home/at14/atintegrators/AperturePass.mexa64, No passFunction or trackFunction available
I've recompiles all the pass methods using "atmexall" and compiles successfully.
Has anyone had this problem before? Windows + Matlab2016a + AT2.0 is OK.
Eugene
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Atcollab-general mailing list
Atc...@li...
https://lists.sourceforge.net/lists/listinfo/atcollab-general
|
|
From: lxyzh <lxh...@hu...> - 2017-08-09 15:35:48
|
Dear all, This is Xu Liu, a PhD candidate in Huazhong University of Science and Technology, China. Recently, I downloaded the AT code and started to calculate beam optics. At the beginning, I followed the installation procedures in your website. But it’s an error, as shown in the following figures. Can you tell me how to solve this problem? Thank you! By the way, the MATLAB version is R2015b win32 and VS2012. -- Best Regards, Liu Xu ============================================================= Liu Xu PhD Candidate Institute of Applied Electromagnetic Engineering (IAEE) School of Electricity and Electronic Engineering(SEEE) Huazhong University of Science and Technology(HUST) Address：C9 113, Luoyu Road 1037#, Wuhan city, Hubei Prov. China 430074 Tel: +(86) - 150-7146-4266 E-mail:lxh...@hu... |
|
From: Eugene T. <Eug...@sy...> - 2017-08-01 09:14:41
|
I just checked the symbols in the compiled files using nm and they do not contain the global symbols for passFunction or trackFunction, only local. Matlab has changed the way it MEXs again.
Matlab2016a
[opi@CR01OPI05 ~]$ cd /usr/local/MATLAB/R2016a/extern/lib/glnxa64/
fexport.map mexFunction.map
Matlab2017a
user@asci: /usr/local/MATLAB/R2017a ls extern/lib/glnxa64/
c_exportsmexfileversion.map fexport.map fortran_exportsmexfileversion.map mexFunction.map
It now has a two layer approach with LINKEXPORT(mexFunction.map) followed by LINKEXPORTVER (c_exportsmexfileversion.map). So what works for me is to make some small changes to the *.map file and mexpassmethod.m (attached). The change appears to have happened in R2016b!
Some nitty gritty detail below if you're interested.
Can people also check that these changes don't break anything before I commit this change to AT2.0?
I don't know how to push this out to AT1.4, so if it works can someone please do this?
Eugene
>> !nm /user/home/at14/atintegrators/AperturePass.mexa64
0000000000000b0c t AperturePass
0000000000000ac5 t atGetDoubleArray
0000000000202090 b __bss_start
0000000000202090 b completed.6344
w __cxa_finalize@@GLIBC_2.2.5
00000000000009e0 t deregister_tm_clones
0000000000000a50 t __do_global_dtors_aux
0000000000201d80 t __do_global_dtors_aux_fini_array_entry
0000000000201d90 d __dso_handle
0000000000201d98 d _DYNAMIC
0000000000202090 d _edata
0000000000202098 b _end
0000000000000d04 t _fini
0000000000000a90 t frame_dummy
0000000000201d78 t __frame_dummy_init_array_entry
0000000000000ed0 r __FRAME_END__
0000000000202000 d _GLOBAL_OFFSET_TABLE_
w __gmon_start__
00000000000008c0 t _init
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
0000000000201d88 d __JCR_END__
0000000000201d88 d __JCR_LIST__
w _Jv_RegisterClasses
0000000000000000 A MEX
U mexErrMsgIdAndTxt
0000000000000cf1 T mexfilerequiredapiversion
0000000000000bfc T mexFunction
U mexMakeMemoryPersistent
U mxCreateCellMatrix@@v7.3
U mxCreateString
U mxDuplicateArray
U mxGetField@@v7.3
U mxGetInf
U mxGetM
U mxGetN
U mxGetPr
U mxIsNaN
U mxMalloc
U mxSetCell@@v7.3
0000000000000a10 t register_tm_clones
0000000000202090 d __TMC_END__
0000000000000ba2 t trackFunction
(small t means local)
>> !nm /user/home/at14/atintegrators/AperturePass.mexa64
0000000000000b3c t AperturePass
0000000000000af5 t atGetDoubleArray
0000000000202090 b __bss_start
0000000000202090 b completed.6344
w __cxa_finalize@@GLIBC_2.2.5
0000000000000a10 t deregister_tm_clones
0000000000000a80 t __do_global_dtors_aux
0000000000201d80 t __do_global_dtors_aux_fini_array_entry
0000000000201d90 d __dso_handle
0000000000201d98 d _DYNAMIC
0000000000202090 d _edata
0000000000202098 b _end
0000000000000d34 t _fini
0000000000000ac0 t frame_dummy
0000000000201d78 t __frame_dummy_init_array_entry
0000000000000f00 r __FRAME_END__
0000000000202000 d _GLOBAL_OFFSET_TABLE_
w __gmon_start__
00000000000008f0 t _init
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
0000000000201d88 d __JCR_END__
0000000000201d88 d __JCR_LIST__
w _Jv_RegisterClasses
0000000000000000 A MEX
U mexErrMsgIdAndTxt
0000000000000d21 T mexfilerequiredapiversion
0000000000000c2c T mexFunction
U mexMakeMemoryPersistent
U mxCreateCellMatrix@@v7.3
U mxCreateString
U mxDuplicateArray
U mxGetField@@v7.3
U mxGetInf
U mxGetM
U mxGetN
U mxGetPr
U mxIsNaN
U mxMalloc
U mxSetCell@@v7.3
0000000000000a40 t register_tm_clones
0000000000202090 d __TMC_END__
0000000000000bd2 T trackFunction
(capital T means global)
Matlab2016a:
LINKEXPORT="-Wl,--version-script,"$MATLABROOT/extern/lib/$ARCH/mexFunction.map""
LDFLAGS="$LDFLAGS $LDTYPE $LINKLIBS $LINKEXPORT"
Matlab2017a:
FUNCTIONMAP=""$MATLABROOT/extern/lib/$ARCH/mexFunction.map""
VERSIONMAP=""$MATLABROOT/extern/lib/$ARCH/c_exportsmexfileversion.map""
LINKEXPORT="-Wl,--version-script,$FUNCTIONMAP"
LINKEXPORTVER="-Wl,--version-script,$VERSIONMAP"
LDFLAGS="-pthread -Wl,--no-undefined -Wl,-rpath-link,$MATLABROOT/bin/$ARCH"
LDFLAGS="$LDFLAGS $LDTYPE $LINKLIBS $LINKEXPORT"
CMDLINE2="$LD $LDFLAGS $LDTYPE $LINKOPTIM $LINKEXPORTVER $OBJS $CLIBS $LINKLIBS -o $EXE"
From: Zeus Martí [mailto:ze...@ce...]
Sent: Tuesday, August 01, 2017 3:47 PM
To: atc...@li...
Subject: Re: [Atcollab-general] help with AT error
Hi there,
We just noticed yesterday some similar problems with a similar configuration "CentOS7 + Matlab2017a + AT1.3". AT1.4 also fails, but AT1.3 has the wonderful ability to crash Matlab2017a every time it is executed. It has been recently updated, the previous version was "CentOS7 + Matlab2015a + AT1.3", so far we workaround using the old release. In our case, the same files are used by different machines with different Matlab versions so we decided not to recompile yet.
Eugene, do you by any chance know if the recompiled files work in earlier versions?
Best regards,
Zeus
On 01/08/2017 5:07, Eugene Tan wrote:
We have been trying to get AT running on CentOS7 + Matlab2017a + AT1.4 and comes up with:
Error using atpass
Element # 0: Library file: /usr/home/at14/atintegrators/AperturePass.mexa64, No passFunction or trackFunction available
I've recompiles all the pass methods using "atmexall" and compiles successfully.
Has anyone had this problem before? Windows + Matlab2016a + AT2.0 is OK.
Eugene
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Atcollab-general mailing list
Atc...@li...<mailto:Atc...@li...>
https://lists.sourceforge.net/lists/listinfo/atcollab-general
|
|
From: Zeus M. <ze...@ce...> - 2017-08-01 05:47:29
|
Hi there, We just noticed yesterday some similar problems with a similar configuration "CentOS7 + Matlab2017a + AT1.3". AT1.4 also fails, but AT1.3 has the wonderful ability to crash Matlab2017a every time it is executed. It has been recently updated, the previous version was "CentOS7 + Matlab2015a + AT1.3", so far we workaround using the old release. In our case, the same files are used by different machines with different Matlab versions so we decided not to recompile yet. Eugene, do you by any chance know if the recompiled files work in earlier versions? Best regards, Zeus On 01/08/2017 5:07, Eugene Tan wrote: > > We have been trying to get AT running on CentOS7 + Matlab2017a + AT1.4 > and comes up with: > > Error using atpass > > Element # 0: Library file: > /usr/home/at14/atintegrators/AperturePass.mexa64, No passFunction or > trackFunction available > > I’ve recompiles all the pass methods using “atmexall” and compiles > successfully. > > Has anyone had this problem before? Windows + Matlab2016a + AT2.0 is OK. > > Eugene > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > Atcollab-general mailing list > Atc...@li... > https://lists.sourceforge.net/lists/listinfo/atcollab-general |
|
From: Eugene T. <Eug...@sy...> - 2017-08-01 03:07:39
|
We have been trying to get AT running on CentOS7 + Matlab2017a + AT1.4 and comes up with: Error using atpass Element # 0: Library file: /usr/home/at14/atintegrators/AperturePass.mexa64, No passFunction or trackFunction available I've recompiles all the pass methods using "atmexall" and compiles successfully. Has anyone had this problem before? Windows + Matlab2016a + AT2.0 is OK. Eugene |
|
From: Boaz N. <boa...@es...> - 2017-07-28 11:27:02
|
Dear all, After some discussion at ESRF, we decided to set August 25 as our date to finish AT2.0. There is always more to be done, but we will do what we can and call it finished at that time. The development is continuing in the at2devel branch in the subversion repository in SourceForge: https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/ <https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/> As mentioned, following this release, we will look for a migration strategy to using git and hosting on github under the atcollab organization: https://github.com/atcollab <https://github.com/atcollab> At the moment, we are doing some cleaning and reorganization of some of the functions in the repository. In particular, some categories have been added to atphysics, and functions are being moved to relevant folders. https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/atmat/atphysics/ <https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/atmat/atphysics/> I may do something similar to the lattice directory https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/atmat/lattice/ <https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/atmat/lattice/> I also created folders in the atdemos directory: https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/atmat/atdemos/ <https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/atmat/atdemos/> There were already some demos here originally by Andrei, but I’ve been adding some new ones. This is a big job, and I hope others will help test and improve these demos. One principle I am trying to follow is to only use lattice files in the machine_data directory: https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/machine_data/ <https://sourceforge.net/p/atcollab/code-0/HEAD/tree/branches/at2devel/machine_data/> These lattice files are still rather varied- some use AT 1.2 style with global variables for the lattice creation, some may include RF cavities and others not. I hope we can use this directory to standardize on what we consider best practice for lattice files. Then if we make sure that all the demos in the atdemos directory run properly, we can be confident that a good amount of AT works properly with these lattice files. Glad to hear comments and get input or help before we release AT2.0. Best regards, Boaz |
|
From: Boaz N. <boa...@es...> - 2017-07-28 09:53:53
|
Yes, I believe that atplot expects a lattice as a column cell array. We’ve never really clarified this issue as to what is an acceptable lattice. Laurent Farvacque sometimes uses 2D arrays in his lattices, where each column is a cell of the machine (with 32 such columns for ESRF). I think standardizing variables is a good idea. I prefer a column vector for a lattice. But I think we should check more carefully compatibility with all the different functions. I do find myself adding a transpose here and there just to make things work. Other people’s opinions? Regards, Boaz > On Jul 28, 2017, at 11:34 AM, <wil...@di...> <wil...@di...> wrote: > > I also found that THERING was transposed in newer versions of AT. > > I don't know what changed though. > > Cheers, > Will > > ________________________________ > From: Eugene Tan [Eug...@sy...] > Sent: 28 July 2017 03:25 > To: atc...@li... > Subject: [Atcollab-general] THERING column or row vector > > Hi all, > > I just came across a problem with “atplot” where it assumed that THERING was a column cell array and will not work if THERING is a row cell array. The old lattice definitions and some of the ones in machine_data return THERING as a row vector. > > Is there a specific reason for this? Are we anticipating that THERING will be 2D where each column is a different lattice? > > For now I’ve made some changes in atbaseplot to force THERING into a column vector ring = ring(:); > > > Eugene > > -- > This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. > Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. > Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. > Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Atcollab-general mailing list > Atc...@li... > https://lists.sourceforge.net/lists/listinfo/atcollab-general |
3 messages has been excluded from this view by a project administrator.
