methodicalacceleratordesign / mad-x

MAD-X repository

MAD-X

MAD-X repository

mad-x's Issues

Add eplacement to the madx_ptc_interface example

Issue migrated from trac ticket # 32

component: _examples | priority: minor | resolution: unresolved

---

2012-01-20 10:29:39: jl nougaret commented

date: 2009.07.10
Check with PS about how to declare the checking of eplacement. To this end, check that the eplacement files are properly located in the CVS repository for the examples.

---

2012-01-20 10:30:15: @ldeniau set resolution to fixed

---

2012-01-20 10:30:15: @ldeniau changed status from new to closed

---

2012-01-20 10:55:41: @ldeniau commented

left as unresolved

---

2012-01-20 10:55:41: @ldeniau changed resolution from fixed to **

---

2012-01-20 10:55:41: @ldeniau changed status from closed to reopened

---

2012-01-20 10:55:48: @ldeniau changed resolution from ** to wontfix

---

2012-01-20 10:55:48: @ldeniau changed status from reopened to closed

---

2012-01-20 11:07:49: @ldeniau changed resolution from wontfix to **

---

2012-01-20 11:07:49: @ldeniau changed status from closed to reopened

---

2012-01-20 11:07:55: @ldeniau changed resolution from ** to unresolved

---

2012-01-20 11:07:55: @ldeniau changed status from reopened to closed

Document the dp-dependency option for ptc_twiss

Issue migrated from trac ticket # 20

component: _doc | priority: minor | resolution: fixed

---

2012-01-19 17:51:46: jl nougaret commented

date: 2009.06.16
The options table does not mention 'deltap-dependency'

---

2012-01-19 17:52:02: @ldeniau commented

updated the documentation as well as the DITA prototype.

---

2012-01-19 17:52:02: @ldeniau set resolution to fixed

---

2012-01-19 17:52:02: @ldeniau changed status from new to closed

DA becomes unstable

Issue migrated from trac ticket # 15

component: ptc_twiss | priority: minor | resolution: fixed

---

2012-01-19 11:12:19: jl nougaret commented

date: 2009.05.05
The following MAD-X file causes a "+++++ warning: ptc_twiss: DA got unstable" message

option,echo;

TITLE, "ALBA-25";

call, file="MAD_input_file.seq";

gamma0=3000/0.510998902;
factn=4*(gamma0^2-1)^(0.5);
exnorm=factn4.5e-9;
eynorm=factn4.5e-12;

Beam,sequence=MACHINE,particle=electron,Energy=3.0,
sige=0.001,Exn=exnorm,Eyn=eynorm;

use,period=MACHINE;

ptc_create_universe;
ptc_create_layout,model=3,method=6,nst=5,exact;
SELECT, flag=ptc_twiss, clear;
SELECT,flag=ptc_twiss,sequence=MACHINE,column=name,keyword,s,beta11,beta22,disp1,x,px,y,py;
PTC_TWISS,no=2,closed_orbit,icase=5,file="twiss.out";
SELECT_PTC_NORMAL,q1=0, dq1=1, q2=0, dq2=1;
PTC_NORMAL,closed_orbit,normal,icase=5,no=2;
WRITE, table=normal_results, file="normal_results.out";
ptc_end;

STOP;

---

2012-01-19 11:14:56: @ldeniau commented

The problem turns out to arise from the use of model=3, when you invoke: ptc_create_layout,model=3,method=6,nst=5,exact;
Instead, please use: ptc_create_layout,model=2,method=6,nst=5,exact;
In general, always prefer model=2 and method=6.

For a complete description of the ptc_create_layout command, please refer to
http://cern.ch/mad/madX/doc/usrguide/ptc_general/ptc_general.html

---

2012-01-19 11:14:56: @ldeniau set resolution to fixed

---

2012-01-19 11:14:56: @ldeniau changed status from new to closed

---

2012-01-19 11:16:25: @ldeniau changed component from _build to ptc_twiss

Add a new option to initialize the map from an ifort.18 file

Issue migrated from trac ticket # 27

component: ptc_twiss | priority: major | resolution: fixed

---

2012-01-19 18:07:51: jl nougaret commented

date: 2009.07.03
add option initial_map_manual to ask ptc_twiss to pickup the initial map from file fort.18.

---

2012-01-19 18:07:57: @ldeniau set resolution to fixed

---

2012-01-19 18:07:57: @ldeniau changed status from new to closed

---

2012-01-19 18:12:27: @ldeniau edited the issue description

---

2012-01-19 18:13:33: @ldeniau changed title from add a new option to initialize the map from an ifort.18 file to Add a new option to initialize the map from an ifort.18 file

ptc_twiss does not handle the table option properly

Issue migrated from trac ticket # 36

component: ptc_twiss | priority: major | resolution: invalid

---

2012-01-20 10:39:37: jl nougaret commented

date: 2009.09.21
By default ptc_twiss relies on a ptc_twiss internal table, whose columns are set by a previous select command. According to the documentation, a user-specified table name may be chosen by setting the option table=tablename. Such user-specified table seems to contain all the columns supported by the ptc_twiss table type instead of the subset specified by the select command.

---

2012-01-20 10:39:58: @ldeniau commented

Actually there is no such bug.
Simply, the table name specified in the ptc_twiss_command should match select,flag=tablename.

---

2012-01-20 10:39:58: @ldeniau set resolution to fixed

---

2012-01-20 10:39:58: @ldeniau changed status from new to closed

---

2012-01-20 11:09:39: @ldeniau changed resolution from fixed to **

---

2012-01-20 11:09:39: @ldeniau changed status from closed to reopened

---

2012-01-20 11:09:49: @ldeniau changed resolution from ** to invalid

---

2012-01-20 11:09:49: @ldeniau changed status from reopened to closed

---

2012-01-20 11:10:00: @ldeniau changed resolution from invalid to **

---

2012-01-20 11:10:00: @ldeniau changed status from closed to reopened

---

2012-01-20 11:10:39: @ldeniau changed resolution from ** to invalid

---

2012-01-20 11:10:39: @ldeniau changed status from reopened to closed

Doc does not indicate the names of some created tables

Issue migrated from trac ticket # 33

component: _doc | priority: major | resolution: unresolved

---

2012-01-20 10:31:51: eberhard.keil commented

date: 2009.08.11
Documentation fails to indicate the names of some tables created by several commands

The documentation should clearly spell out the names of internal tables created by several commands such as ptc_track and ptc_run.

---

2012-01-20 10:32:09: @ldeniau set resolution to fixed

---

2012-01-20 10:32:09: @ldeniau changed status from new to closed

---

2012-01-20 10:46:07: @ldeniau commented

left as unresolved

---

2012-01-20 10:57:14: @ldeniau commented

left as unresolved

---

2012-01-20 10:57:14: @ldeniau edited the issue description

---

2012-01-20 10:57:14: @ldeniau changed resolution from fixed to **

---

2012-01-20 10:57:14: @ldeniau changed status from closed to reopened

---

2012-01-20 10:57:19: @ldeniau changed resolution from ** to wontfix

---

2012-01-20 10:57:19: @ldeniau changed status from reopened to closed

---

2012-01-20 11:07:33: @ldeniau changed resolution from wontfix to **

---

2012-01-20 11:07:33: @ldeniau changed status from closed to reopened

---

2012-01-20 11:07:37: @ldeniau changed resolution from ** to unresolved

---

2012-01-20 11:07:37: @ldeniau changed status from reopened to closed

Intel compiler split standard output lines after 80 characters

Issue migrated from trac ticket # 19

component: core_stream | priority: major | resolution: fixed

---

2012-01-19 17:46:55: jl nougaret commented

date: 2009.05.28
Unless the ouput is explicitly formatted, such as in a write(6,'(a)') statement, write(6,*) and print * statements will generate output that splits after 80 characters. So far, this happens with the Intel compiler.

---

2012-01-19 17:49:52: @ldeniau commented

2009.05.28
By setting the environment variable FORT_FMT_RECL to a large number, e.g. 256, before executing the MAD-X executable, the lines are allowed to run up to the given number of characters.
Unless we can solve this with a compiler option (/ccdefault?), it would be better to set such environment variable from within MAD-X rather than externally.

2009.06.08
Instead of relying on the above mentioned environment variable, Eric McIntosh found out the way to force the record length from within the Fortran program.

(1) First the Fortran program needs to be compiled with specific /assume/noold_unit_star option, as in:

ifort /c /names:lowercase /assume:underscore /assume:noold_unit_star -D_INTEL_IFORT_SET_RECL /fpp /O2 -D_INTEL_IFORT_FLUSH madx_main.F90

(2) the Fortran code madx_main contains:

program madx_main
use run_madx
implicit none

#ifdef _INTEL_IFORT_SET_RECL
include 'mad_recl.fi'
open(unit=6,RECL=mad_record_length)
#endif

call madxm
stop
end program madx_main

2009.06.30
apparently works if os.putenv('FORT_FMT_RECL'.'256') for the automatic test, but open(unit=6,RECL=...) does not seem to work when invoking the madx executable compiled with ifort.

2010.04.15
when invoking the makefile:
make FORT_FMT_RECL=256
This solves the problem. Used in MadBuidl.py.

2010.05.04
does not longer work since SVN replaced CVS.

2010.05.04
Works again after modifying MadBuild.py:
(1) removed os.environ['FORT_FMT_RECL']='256'
(2) make file invocation set to: make f95=ifort DEBUG=NO FORT_FMT_RECL=256 madx

---

2012-01-19 17:49:52: @ldeniau set resolution to fixed

---

2012-01-19 17:49:52: @ldeniau changed status from new to closed

Create link to mad-x-old on Windows

Issue migrated from trac ticket # 6

component: _rep | priority: major | resolution: fixed

---

2012-01-19 10:38:36: jl nougaret commented

date: 2009.03.26
On Windows, the "BV flag kill initiative" means that from version 4.0, old sequences can no longer be read. The 3.04.53 version of MAD-X is the latest version that can read such old sequences. It will be archived as mad-x-old and shall be accessible from the website where MAD-X Windows versions are downloaded.

---

2012-01-19 10:38:56: @ldeniau commented

For 3.04.53, madx.exe and madxp.exe have been compiled and installed under ~/www/mad/windows-binaries/madx-old.exe and madxp-old.exe. The web page created by MadTrigRelease.pl now systematically creates links to these two executables.

---

2012-01-19 10:38:56: @ldeniau set resolution to fixed

---

2012-01-19 10:38:56: @ldeniau changed status from new to closed

Implement center_magnets option in ptc_twiss

Issue migrated from trac ticket # 40

component: ptc_twiss | priority: major | resolution: fixed

---

2012-01-20 11:15:29: jl nougaret commented

date: 2010.03.02
Evaluate the Twiss function at the middle of each element and only there.

---

2012-01-20 11:15:42: @ldeniau set resolution to fixed

---

2012-01-20 11:15:42: @ldeniau changed status from new to closed

---

2012-01-20 11:18:46: @ldeniau edited the issue description

Fix automatic Windows compilation

Issue migrated from trac ticket # 35

component: _build | priority: major | resolution: fixed

---

2012-01-20 10:35:56: jl nougaret commented

date: 2009.08.12
MadWindowsCompileClient.py no longer works.

---

2012-01-20 10:36:32: @ldeniau commented

Proceed even if the compilation sandbox is absent on the windows host.

---

2012-01-20 10:36:32: @ldeniau edited the issue description

---

2012-01-20 10:36:32: @ldeniau set resolution to fixed

---

2012-01-20 10:36:32: @ldeniau changed status from new to closed

Refresh Kerberos AFS token beyond 5+1 days

Issue migrated from trac ticket # 18

component: _build | priority: major | resolution: fixed

---

2012-01-19 14:14:41: jl nougaret commented

date: 2009.05.26
According to IT documentation, one should be able to refresh the Kerberos ticket for as long as 10 days, with kinit -R. In practice, the initial kinit assumes only 5 days unless otherwise specified with kinit -r 10days which requires password. The approach does not work with a cron job.

---

2012-01-19 14:15:02: @ldeniau commented

Rely on a keytab, always relying on "kinit -k -t mykeytab nougaret" instead of periodic refreshes with "kinit -R".

---

2012-01-19 14:15:02: @ldeniau set resolution to fixed

---

2012-01-19 14:15:02: @ldeniau changed status from new to closed

Fails to compile on Windows

Issue migrated from trac ticket # 43

component: _build | priority: major | resolution: fixed

---

2012-01-20 11:22:19: jl nougaret commented

date: 2010.03.17
After Frank set globals in module instead of include .fi files, the USE Fortran statements fail to compile.

---

2012-01-20 11:22:31: @ldeniau commented

Fixed by inserting the following in MakefileIntel.bat
INCLUDE="."

---

2012-01-20 11:22:31: @ldeniau set resolution to fixed

---

2012-01-20 11:22:31: @ldeniau changed status from new to closed

Make a script to x-check transverse installation shifts

Issue migrated from trac ticket # 22

component: _tools | priority: major | resolution: fixed

---

2012-01-19 17:58:34: jl nougaret commented

date: 2009.07.03
create a script to cross check the transverse installation shifts used for the measured profiles.

Script #2
Aim: cross check the transverse installation shifts used for the measured profiles. The file names should/could be free parameters
Input files: lhc_mech_axis_noshifts-b*.madx (measured profiles without shifts)
lhc_mech_axis_shifts-b.madx (measured profiles including shifts)
Output file: five columns (magnet name, computed_x_shift, computed_y_shift, used_x_shift, used_y_shift)
Message stating whether the check was successful or not (and the number of incorrect shifts)

---

2012-01-19 17:58:48: @ldeniau commented

apershift.py available under ~nougaret/public/apershift.py.

---

2012-01-19 17:58:48: @ldeniau set resolution to fixed

---

2012-01-19 17:58:48: @ldeniau changed status from new to closed

Retrieve values in the header of a TFS table

Issue migrated from trac ticket # 48

component: core_table | priority: minor | resolution: wontfix

---

2012-01-20 11:35:12: jl nougaret commented

date: 2010.04.08
it is not possible to retrieve values in the header of a TFS table

---

2012-01-20 11:35:54: @ldeniau commented

values that can be retrieved are made available in dedicated TFS tables like the summay or ptc_twiss_summary tables.

---

2012-01-20 11:35:54: @ldeniau set resolution to wontfix

---

2012-01-20 11:35:54: @ldeniau changed status from new to closed

Make documentation for new set of features

Issue migrated from trac ticket # 29

component: ptc_twiss | priority: major | resolution: fixed

---

2012-01-19 18:11:10: jl nougaret commented

date: 2009.07.03
(1) - new columns disp1p2,... disp6p2 and disp1p3,...disp6p2 to accommodate second and third order derivatives of the dispersion w.r.t. delta-p.
(2) - added a new option 'initial_map_manual' to tell ptc_twiss that the map must be initialized from the one stored in the fort.18 file.

---

2012-01-19 18:11:24: @ldeniau commented

2009.07.03
done, except the example.

2010.04.15
The derivatives of the dispersion w.r.t. deltap/p have column names: disp1p,...,disp4p. Second and third order derivatives have respective column names: disp1p2,...,disp4p2 for the second order, and disp1p3,...,disp4p3 for the third order.
INITIAL_MAP_MANUAL is defined.

---

2012-01-19 18:11:24: @ldeniau set resolution to fixed

---

2012-01-19 18:11:24: @ldeniau changed status from new to closed

---

2012-01-19 18:13:59: @ldeniau changed title from create documentation for new set of features to Make documentation for new set of features

Show closed orbits RMS and MAX in the header and summary

Issue migrated from trac ticket # 46

component: ptc_twiss | priority: major | resolution: fixed

---

2012-01-20 11:29:22: jl nougaret commented

date: 2010.04.06
As for twiss, the header and ptc_twiss_summary table shall contain the RMS and max values of the closed orbit.

---

2012-01-20 11:29:31: @ldeniau set resolution to fixed

---

2012-01-20 11:29:31: @ldeniau changed status from new to closed

Memory leak due to repeated creation of TFS tables

Issue migrated from trac ticket # 1

component: core_memory | priority: major | resolution: wontfix

---

2012-01-19 10:13:20: jl nougaret commented

date: 2009.03.20
Successive invocation of functions such as twiss or ptw_twiss cause repeated creations of TFS tables. The table is not being deleted before being recreated, which causes a memory leak. Note that for a user-defined TFS table, one should manually 'delete' the table.

---

2012-01-19 10:15:49: @ldeniau commented

Frank decided to not fix this memory leak, considering the core is too fragile.

---

2012-01-19 10:15:49: @ldeniau set resolution to wontfix

---

2012-01-19 10:15:49: @ldeniau changed status from new to closed

---

2012-01-19 10:29:41: @ldeniau edited the issue description

Memory leak when calling a file

Issue migrated from trac ticket # 3

component: core_memory | priority: major | resolution: wontfix

---

2012-01-19 10:27:54: jl nougaret commented

date: 2009.03.25
When the MAD-X interpreter encounters a 'call,file' where the file is non-empty, a memory leak is created.

---

2012-01-19 10:28:53: @ldeniau commented

date: 2009.03.25
Frank decided not to fix this memory leak, considering the core is too fragile.

---

2012-01-19 10:28:53: @ldeniau set resolution to wontfix

---

2012-01-19 10:28:53: @ldeniau changed status from new to closed

---

2012-01-20 11:30:48: @ldeniau edited the issue description

Compute summary information for transfer lines and rings

Issue migrated from trac ticket # 28

component: ptc_twiss | priority: major | resolution: fixed

---

2012-01-19 18:09:15: jl nougaret commented

date: 2009.07.03

---

2012-01-19 18:11:46: @ldeniau set resolution to fixed

---

2012-01-19 18:11:46: @ldeniau changed status from new to closed

---

2012-01-19 18:13:45: @ldeniau changed title from compute summary information for transfer lines and rings to Compute summary information for transfer lines and rings

Memory leak observed with a trivial empty sequence

Issue migrated from trac ticket # 4

component: core_memory | priority: major | resolution: wontfix

---

2012-01-19 10:33:37: jl nougaret commented

date: 2009.03.25
We observe a memory leak for a trivial MAD-X script containing a single empty sequence. One way to fix the leak is to deallocate this_cmd, in case this_cmd->type ==3 at the end of the process() function of madxp.c, as listed below. Unfortunately, it is not clear at this stage whether this approach suffers side-effects. Moreover, it may well be the case that type 3 commands such as 'sequence' and 'endsequence' are not meant to be deallocated.

if (this_cmd !# NULL && (this_cmd->type ## 0 || this_cmd->type 2 || this_cmd->type= 3)) {
if (this_cmd->clone != NULL) {
if (this_cmd->clone_flag == 0)
this_cmd->clone = delete_command(this_cmd->clone);
else
add_to_command_list(this_cmd->clone->name, this_cmd->clone, stored_commands, 0);
}
if (this_cmd->label != NULL)
buffer_in_cmd(this_cmd);
else
this_cmd = delete_in_cmd(this_cmd);
}

---

2012-01-19 10:33:58: @ldeniau commented

Frank decided not to fix this memory leak, considering the core is too fragile.

---

2012-01-19 10:33:58: @ldeniau set resolution to wontfix

---

2012-01-19 10:33:58: @ldeniau changed status from new to closed

Accessing values of the ptc_twiss_summary table

Issue migrated from trac ticket # 37

component: ptc_twiss | priority: major | resolution: fixed

---

2012-01-20 10:41:38: jl nougaret commented

date: 2010.02.02
In order to retrieve the value of dq1 from the ptc_twiss_summary table, one must pass an extra "1": value, table(ptc_twiss_summary,dq1,1);

---

2012-01-20 10:42:18: @ldeniau commented

I made the ptc_twiss_summary table a static one.
Now "value, table(ptc_twiss_summary,dq1);" works without the extra ",1".

---

2012-01-20 10:42:18: @ldeniau set resolution to fixed

---

2012-01-20 10:42:18: @ldeniau changed status from new to closed

Mixed-up output between Fortran and C

Issue migrated from trac ticket # 9

component: core_stream | priority: major | resolution: fixed

---

2012-01-19 10:46:49: jl nougaret commented

date: 2009.03.31
In order to avoid mixup of the outputs from C and Fortran, some wrappers of Fortran calls have been put it place. But guarding the reverse direction, namely C wrapping calls from Fortran, might be necessary to prevent output garble-up in all cases.

---

2012-01-19 10:47:16: @ldeniau commented

The Windows Makefile.bat must be edited so as to take into account of the improvement. In the meantime, only Fortran calls from C are wrapped to ensure systematic flush of stdout when crossing the border.

---

2012-01-19 10:47:16: @ldeniau set resolution to fixed

---

2012-01-19 10:47:16: @ldeniau changed status from new to closed

Carry-out performance analysis

Issue migrated from trac ticket # 14

component: _perf | priority: major | resolution: fixed

---

2012-01-19 11:07:46: jl nougaret commented

date: 2009.04.23
MAD-8 outperforms MAD-X by a factor 4 to 5 on the LEP example. Carry-out some performance analysis to explain and reduce such a gap in speed.

---

2012-01-19 11:08:48: @ldeniau uploaded file mad8_tmfrst_detailed_callgr.gif (45.5 KiB)

---

2012-01-19 11:09:00: @ldeniau uploaded file madx_tmfrst_detailed_callgr.gif (69.2 KiB)

---

2012-01-19 11:10:09: @ldeniau commented

The included graphs were sent to Hans together with indications on how to carry-out profiling. This showed extensive string manipulations, which I could speed-up by optimizing the strcmp function through checking the first character before deciding to invoke the standard strcmp. This yielded 30% improvement. Later on, Hans managed a 3 fold performance improvement, with successive trials.

---

2012-01-19 11:10:09: @ldeniau set resolution to fixed

---

2012-01-19 11:10:09: @ldeniau changed status from new to closed

Add a routine to display the list of existing tables

Issue migrated from trac ticket # 34

component: core_table | priority: minor | resolution: unresolved

---

2012-01-20 10:33:55: eberhard.keil commented

date: 2009.08.11
In addition, a little service routine, SHOWTABLES or similar, that lists the existing tables with their names on the screen, might help users to don't like reading documentation.
This issue was raised by Eberhard Keil.

---

2012-01-20 10:37:07: @ldeniau set resolution to wontfix

---

2012-01-20 10:37:07: @ldeniau changed status from new to closed

---

2012-01-20 10:45:47: @ldeniau commented

left as unresolved

---

2012-01-20 10:58:35: @ldeniau commented

left as unresolved

---

2012-01-20 10:58:35: @ldeniau changed resolution from wontfix to **

---

2012-01-20 10:58:35: @ldeniau changed status from closed to reopened

---

2012-01-20 10:58:42: @ldeniau changed resolution from ** to wontfix

---

2012-01-20 10:58:42: @ldeniau changed status from reopened to closed

---

2012-01-20 11:08:12: @ldeniau changed resolution from wontfix to **

---

2012-01-20 11:08:12: @ldeniau changed status from closed to reopened

---

2012-01-20 11:08:18: @ldeniau changed resolution from ** to unresolved

---

2012-01-20 11:08:18: @ldeniau changed status from reopened to closed

initial_matrix_table option must updated to new map_table format

Issue migrated from trac ticket # 50

component: ptc_twiss | priority: major | resolution: fixed

---

2012-01-20 11:40:22: jl nougaret commented

date: 2010.04.26
Since the format of the map_table has changed to accommodate orders higher than one, the routine that reads the map_table in must be modified accordingly.

---

2012-01-20 11:40:48: @ldeniau commented

Seems to work: ptc_twiss Example3 issues no warning and fort.28 (now commented in the code) is identical to fort.18 created by ptc_normal, but the last (6th) coordinate for icase=5.

---

2012-01-20 11:40:48: @ldeniau set resolution to fixed

---

2012-01-20 11:40:48: @ldeniau changed status from new to closed

Tests dependency graph misses "readtable" calls

Issue migrated from trac ticket # 11

component: _tests | priority: major | resolution: fixed

---

2012-01-19 10:53:36: jl nougaret commented

date: 2009.04.01
MAD-X commands such as:
readtable, file="rotations_Q2_integral.tab";
are not yet parsed by MadTest.pl, which thus fails to copy the file locally.

---

2012-01-19 10:53:54: @ldeniau set resolution to fixed

---

2012-01-19 10:53:54: @ldeniau changed status from new to closed

Fail to compile a standalone executable on Windows

Issue migrated from trac ticket # 13

component: _build | priority: major | resolution: fixed

---

2012-01-19 11:03:08: jl nougaret commented

date: 2009.04.22
The new C++ code for TPSA requires a newer STL and compiler, which in turn rely on a newer multithreaded of the standard libc (libcmt). Lahey Fortran relies on an older single-threaded version of libc.lib which is conflicting. To overcome this limitation, the TPSA code has been packaged as a dll for dynamic loading at run time. At present, this would require delivering MAD-X together with the TPSA dll. To avoid this, experiment with Intel Fortran compiler, as a possible replacement for Lahey Fortran.

---

2012-01-19 11:04:27: @ldeniau commented

2009.04.23
With the proper compiler options, link almost works but for _flush and call_fortran_flush
Link works if I force WRAP_FORTRAN_CALLS to 0, which means the output will be garbled-up
2009.04.23
The program now compiles as a standalone executable that also links with Visual Studio 2008 C++.

---

2012-01-19 11:04:27: @ldeniau set resolution to fixed

---

2012-01-19 11:04:27: @ldeniau changed status from new to closed

Adapt automated build to the new makefile

Issue migrated from trac ticket # 7

component: _build | priority: major | resolution: fixed

---

2012-01-19 10:40:20: jl nougaret commented

date: 2009.03.27
The three default and debug makefiles are now merged into one, with lf95 and DEBUG options to be passed according to the following rules:
f95=lf95, DEBUG=YES stands for the old Makefile_develop
f95=f95, DEBUG=YES stands for the old Makefile_nag
f95=/opt/intel/Compiler/11.0/081/bin/ia32/ifort on pcslux99, DEBUG=NO, stands for the old Makefile

In addition, madxp is now a symbolic link on madx

---

2012-01-19 10:41:01: @ldeniau commented

In MadBuild.pl, Makefile is invoked with the proper f95 and DEBUG variables. However, the web page is still mentioning Makefile, Makefile_develop and Makefile_nag

---

2012-01-19 10:41:01: @ldeniau edited the issue description

---

2012-01-19 10:41:01: @ldeniau set resolution to fixed

---

2012-01-19 10:41:01: @ldeniau changed status from new to closed

Make a script to reflect the data in layoutapertures.madx

Issue migrated from trac ticket # 23

component: _tools | priority: major | resolution: fixed

---

2012-01-19 18:00:42: jl nougaret commented

date: 2009.06.03
create a script to reflect the data in layoutapertures.madx to convert it in a "beam 4" reference system.

Script # 3
Aim: reflect the data in layoutapertures.madx (always referred to Beam 1/2) to convert it into Beam 4 reference system. The script used to reflect the sequence can be re-used (in this case the only parameter to changed for each marker is mech_sep -> -mech_sep)

---

2012-01-19 18:00:55: @ldeniau set resolution to fixed

---

2012-01-19 18:00:55: @ldeniau changed status from new to closed

ptc_twiss should get rid of the delta_dependency flag

Issue migrated from trac ticket # 41

component: ptc_twiss | priority: minor | resolution: unresolved

---

2012-01-20 11:17:57: jl nougaret commented

date: 2010.03.02
ptc_twiss currently expects the user to set a delta_dependency flag when it wants to fill in columns such as beta11p, disp1p etc... This flag could be implicit and internally set each time one of the corresponding columns is selected. This would ease the work of the user but requires sophistication of the implementation.

---

2012-01-20 11:18:25: @ldeniau edited the issue description

---

2012-01-20 11:18:25: @ldeniau set resolution to unresolved

---

2012-01-20 11:18:25: @ldeniau changed status from new to closed

Add examples of 6D usage with Qs in ptc_twiss examples

Issue migrated from trac ticket # 44

component: _examples | priority: major | resolution: unresolved

---

2012-01-20 11:23:54: jl nougaret commented

date: 2010.03.26
empty

---

2012-01-20 11:24:00: @ldeniau set resolution to unresolved

---

2012-01-20 11:24:00: @ldeniau changed status from new to closed

Improve maptable option to produce complete map_table

Issue migrated from trac ticket # 45

component: ptc_normal | priority: major | resolution: fixed

---

2012-01-20 11:26:04: jl nougaret commented

date: 2010.03.30

---

2012-01-20 11:26:27: @ldeniau commented

The order is slightly different from the order in fort.18 but all terms are present.
Implementation in madx_ptc_module.f90 although this is a feature of madx_ptc_normal.f90.

---

2012-01-20 11:26:27: @ldeniau set resolution to fixed

---

2012-01-20 11:26:27: @ldeniau changed status from new to closed

Port the test suite to SLC5

Issue migrated from trac ticket # 49

component: _build | priority: major | resolution: fixed

---

2012-01-20 11:37:53: jl nougaret commented

date: 2010.04.15

---

2012-01-20 11:38:13: @ldeniau commented

/usr/sue/bin/kinit left untouched.
/usr/sue/bin/klist changed to /usr/kerberos/bin/klist.

---

2012-01-20 11:38:13: @ldeniau set resolution to fixed

---

2012-01-20 11:38:13: @ldeniau changed status from new to closed

Automation scripts should only refer to madx

Issue migrated from trac ticket # 2

component: _tests | priority: minor | resolution: fixed

---

2012-01-19 10:23:31: jl nougaret commented

date: 2009.03.25
From now on, madxp is just a link on madx. Therefore all references to madxp should be replaced by references to madx in the automation scripts and TestScenario.xml. Wherever the list ('madx','madxp') is considered, as in MadBuild.pl, one should reduce the list to ('madx').

---

2012-01-19 10:24:50: @ldeniau commented

All references to madxp have been removed from TestScenario.xml and the xslt transform.

---

2012-01-19 10:24:50: @ldeniau set resolution to fixed

---

2012-01-19 10:24:50: @ldeniau changed status from new to closed

Set the value of opt_fun dimension fundim to 150

Issue migrated from trac ticket # 30

component: ptc_twiss | priority: minor | resolution: fixed

---

2012-01-19 18:16:14: jl nougaret commented

date: 2009.07.08
Set the value of opt_fun dimension fundim to 150 and access it from all madx_ptc fortran files.

opt_fun is a local variable of dimension 74 in twiss0.fi, 72 in madx_ptc_knobs.f90 and 150 in ptc_twiss.f90. Frs wants to keep it a local variable and to ensure that the array size is identical, i.e. 150, read from twiss0.fi.

---

2012-01-19 18:16:20: @ldeniau set resolution to fixed

---

2012-01-19 18:16:20: @ldeniau changed status from new to closed

---

2012-01-20 10:53:41: @ldeniau commented

left as unresolved

Make a script to generate offset files for beam 1, 2 and 4

Issue migrated from trac ticket # 24

component: _tools | priority: major | resolution: unresolved

---

2012-01-19 18:02:10: jl nougaret commented

date: 2009.06.03
create a script to generate offset files for beam 1, 2 and 4

Script # 4
Aim: generate offset files for beam 1, beam 2 and beam 4 (structure of the files described in the Aperture module section of the MAD-X manual).
Input file: layoutapertures.madx
Output files: one offset file for each IR and each beam
The horizontal offset to be defined for each marker is computed according to
Offset= sgn[mech_sep] (mech_sep/2 - 0.097)

---

2012-01-19 18:02:15: @ldeniau set resolution to fixed

---

2012-01-19 18:02:15: @ldeniau changed status from new to closed

---

2012-01-19 18:05:13: @ldeniau changed title from create a script to generate offset files for beam 1, 2 and 4 to Make a script to generate offset files for beam 1, 2 and 4

---

2012-01-20 10:52:09: @ldeniau commented

left as unresolved

---

2012-01-20 10:52:09: @ldeniau changed resolution from fixed to **

---

2012-01-20 10:52:09: @ldeniau changed status from closed to reopened

---

2012-01-20 10:52:26: @ldeniau changed resolution from ** to wontfix

---

2012-01-20 10:52:26: @ldeniau changed status from reopened to closed

---

2012-01-20 11:06:20: @ldeniau changed resolution from wontfix to **

---

2012-01-20 11:06:20: @ldeniau changed status from closed to reopened

---

2012-01-20 11:06:25: @ldeniau changed resolution from ** to unresolved

---

2012-01-20 11:06:25: @ldeniau changed status from reopened to closed

Commit ptc_twiss examples

Issue migrated from trac ticket # 10

component: _examples | priority: major | resolution: fixed

---

2012-01-19 10:49:11: jl nougaret commented

date: 2009.03.31
Most examples require a re-commit of the output file. But the delta-dependency example exhibits severe discrepancies between madX-4_00_007 and madX-4_00_00. For instance the output is mixed up between Fortran and C, as well as numerical discrepancies.

---

2012-01-19 10:51:50: @ldeniau commented

2009.04.03
Recompiled, ran and committed the outcome for DeltaDependency.
2009.06.08
suspended until a new bug-free version is released.
2009.07.03
New version takes into account the second and third order derivatives of the dispersion w.r.t delta-p/p.
Recompiled, ran and committed DeltaDependency with madX-4_00_29 (debug version), and setting environment variable FORT_FMT_RECL to 256.
2009.07.10
A new update will be necessary to check the alphac derivative w.r.t deltap.

---

2012-01-19 10:51:50: @ldeniau changed component from _tests to _examples

---

2012-01-19 10:51:50: @ldeniau set resolution to fixed

---

2012-01-19 10:51:50: @ldeniau changed status from new to closed

Repeated invocation of ptc_twiss spoils Beta extrema

Issue migrated from trac ticket # 39

component: ptc_twiss | priority: major | resolution: fixed

---

2012-01-20 11:13:44: jl nougaret commented

date: 2010.02.10
When entering ptc_twiss one should reset the extrema of the Beta function to an uninitialized state.

---

2012-01-20 11:13:53: @ldeniau set resolution to fixed

---

2012-01-20 11:13:53: @ldeniau changed status from new to closed

ptc_twiss behavior depends on selected 4D, 5D or 6D

Issue migrated from trac ticket # 16

component: ptc_twiss | priority: major | resolution: na

---

2012-01-19 11:20:26: jl nougaret commented

date: 2009.05.06
For instance, dispersion and delta-dependencies are 4D concepts, with delta being supplied as an external parameter. Otherwise, delta is part of the phase space...

---

2012-01-19 11:23:49: @ldeniau commented

In 4D, deltap=0 and there's no dispersion.

In 5D: four dimensional + deltap/p ==> cT pathlength =0
In this case deltap/p<>0 is an external parameters and our simple formulas hold for the derivatives w.r.t. deltap/p of the Twiss parameters and dispersion.

In 6D: deltap/p is part of the phase space and our simplified formula no longer hold.

---

2012-01-19 11:23:49: @ldeniau set resolution to notapplicable

---

2012-01-19 11:23:49: @ldeniau changed status from new to closed

---

2012-01-19 11:23:49: @ldeniau changed type from defect to info

---

2012-01-19 11:24:28: @ldeniau changed title from ptc_twiss behavior depends on selected dim 4D, 5D or 6D to ptc_twiss behavior depends on selected 4D, 5D or 6D

---

2012-01-20 11:05:21: @ldeniau changed resolution from na to **

---

2012-01-20 11:05:21: @ldeniau changed status from closed to reopened

---

2012-01-20 11:05:42: @ldeniau changed resolution from ** to na

---

2012-01-20 11:05:42: @ldeniau changed status from reopened to closed

Automation scripts should no longer refer to mpars

Issue migrated from trac ticket # 5

component: _build | priority: major | resolution: fixed

---

2012-01-19 10:35:52: jl nougaret commented

date: 2009.03.26
The mpars target has disappeared from MAD-X 4.0. Windows compilation scripts should no longer deliver the mpars target.

---

2012-01-19 10:36:37: @ldeniau edited the issue description

---

2012-01-19 10:36:37: @ldeniau set resolution to fixed

---

2012-01-19 10:36:37: @ldeniau changed status from new to closed

Use absolute instead of relative tolerance for some cases

Issue migrated from trac ticket # 17

component: _tests | priority: minor | resolution: fixed

---

2012-01-19 14:12:27: jl nougaret commented

date: 2009.05.08
When the MadDiff.pl script compares the output of the new version of an example with its reference output, it compares if numbers match within the numerical (relative) tolerance.
If they match, it issues a warning. If not, an error.
For some cases such as matching, EL and FT propose to rely on absolute rather than relative tolerance.

---

2012-01-19 14:12:36: @ldeniau set resolution to fixed

---

2012-01-19 14:12:36: @ldeniau changed status from new to closed

ptc_twiss prints incomplete tables in case of unstable motion

Issue migrated from trac ticket # 38

component: ptc_twiss | priority: minor | resolution: unresolved

---

2012-01-20 10:44:35: eberhard.keil commented

date: 2010.02.02
PTC_TWISS prints the TFS table header and the column labels before it discovers that the motion is unstable and the table cannot be calculated. By moving a handful of lines to after the stability test would make sure that PTC_TWISS only writes clean tables.

---

2012-01-20 10:44:52: @ldeniau commented

left as unresolved

---

2012-01-20 10:44:52: @ldeniau set resolution to fixed

---

2012-01-20 10:44:52: @ldeniau changed status from new to closed

---

2012-01-20 10:59:17: @ldeniau commented

left as unresolved

---

2012-01-20 10:59:17: @ldeniau changed resolution from fixed to **

---

2012-01-20 10:59:17: @ldeniau changed status from closed to reopened

---

2012-01-20 10:59:25: @ldeniau changed resolution from ** to wontfix

---

2012-01-20 10:59:25: @ldeniau changed status from reopened to closed

---

2012-01-20 11:08:33: @ldeniau changed resolution from wontfix to **

---

2012-01-20 11:08:33: @ldeniau changed status from closed to reopened

---

2012-01-20 11:08:39: @ldeniau changed resolution from ** to unresolved

---

2012-01-20 11:08:39: @ldeniau changed status from reopened to closed

Tests should consider 0 and -0 as identical

Issue migrated from trac ticket # 8

component: _tests | priority: minor | resolution: fixed

---

2012-01-19 10:43:04: jl nougaret commented

date: 2009.03.31
The testing script MadDiff.pl indicates an error in case the left hand side and right hand side examples exhibit a 0 and -0 respectively. Either one should ensure that the code always prints out 0, or one should fix the script to consider that 0 and -0 are identical.

---

2012-01-19 10:43:22: @ldeniau commented

Such differences will display as a warning that 0 and -0 differ within the allowed numerical tolerance.

---

2012-01-19 10:43:22: @ldeniau set resolution to fixed

---

2012-01-19 10:43:22: @ldeniau changed status from new to closed

---

2012-01-19 10:44:07: @ldeniau changed title from Example checking should consider that 0 and -0 are identical to Tests should consider 0 and -0 as identical

Compute alpha_c 1st order derivatives w.r.t. delta-p

Issue migrated from trac ticket # 26

component: ptc_twiss | priority: major | resolution: fixed

---

2012-01-19 18:06:57: jl nougaret commented

date: 2009.07.03

---

2012-01-19 18:07:01: @ldeniau set resolution to fixed

---

2012-01-19 18:07:01: @ldeniau changed status from new to closed

---

2012-01-19 18:13:22: @ldeniau changed title from compute alpha_c firts order derivatives w.r.t. delta-p to Compute alpha_c 1st order derivatives w.r.t. delta-p

Compute dispersion's derivatives w.r.t dp up to 3rd order

Issue migrated from trac ticket # 25

component: ptc_twiss | priority: major | resolution: fixed

---

2012-01-19 18:03:56: jl nougaret commented

date: 2009.07.03
compute dispersion's derivatives w.r.t delta-p up to the third order

---

2012-01-19 18:04:09: @ldeniau commented

checked by approximating derivatives by finite differences.

---

2012-01-19 18:04:09: @ldeniau set resolution to fixed

---

2012-01-19 18:04:09: @ldeniau changed status from new to closed

---

2012-01-19 18:13:00: @ldeniau changed title from compute dispersion's derivatives w.r.t dp up to 3rd order to Compute dispersion's derivatives w.r.t dp up to 3rd order

Plot aborts for user table under certain circumstances

Issue migrated from trac ticket # 42

component: mod_plot | priority: major | resolution: wontfix

---

2012-01-20 11:20:58: jl nougaret commented

date: 2010.03.03
Consider the following script:
while(n<5){
x=n;
y=n*n;
value,table(mytable,x);
value,table(mytable,y);
fill,table=mytable;
n=n+1;
}
write,table=mytable;
plot,table=mytable,haxis=x,vaxis=y;

It aborts with a memory corruption unless a beam and a sequence are defined first, which should not be the case. For the given script, one can fix the problem by artificially replacing the script by:

create,table=mytable,column=x,y;
n=0;

! ALL THE FOLLOWING SETUP NECESSARY FOR THE PLOT TO PROCEED!!!-------
! define a default beam (otherwise fatal error)
beam;
! Define element classes for a simple cell:
b: sbend,l=35.09, angle = 0.011306116;
qf: quadrupole,l=1.6,k1=-0.02268553;
qd: quadrupole,l=1.6,k1=0.022683642;
sf: sextupole,l=0.4,k2=-0.13129;
sd: sextupole,l=0.76,k2=0.26328;
! define the cell as a sequence:
sequ: sequence,l=79;
b1: b, at=19.115;
sf1: sf, at=37.42;
qf1: qf, at=38.70;
b2: b, at=58.255,angle=b1->angle;
sd1: sd, at=76.74;
qd1: qd, at=78.20;
endm: marker, at=79.0;
endsequence;
use period=sequ;
!--------------------------------------------------------------------

while(n<5){
x=n;
y=n*n;
value,table(mytable,x);
value,table(mytable,y);
fill,table=mytable;
n=n+1;
}
write,table=mytable;
plot,table=mytable,haxis=x,vaxis=y;

---

2012-01-20 11:21:12: @ldeniau set resolution to wontfix

---

2012-01-20 11:21:12: @ldeniau changed status from new to closed

Interpolation in drift space

Issue migrated from trac ticket # 47

component: ptc_twiss | priority: major | resolution: unresolved

---

2012-01-20 11:34:03: jl nougaret commented

date: 2010.04.06
As requested by JB Jeanneret:
To summarize our discussion :

users are frequently embarassed by the lack of (ptc-)twiss data in between elements (or inside).
This either internally for matching constraints like bet > bet_min (min is always in between quads, or externally for integrating along s functions which depends on twiss data.

It would be great if similarly to what 'PLOT, interpolate' does, a command would allow to create a table (which can be saved to file) with selected Twiss functions at every node as given by interpolate.

This could be made (at the simplest) together with either TWISS or PTC_TWISS.

Time-scale at best with you ...

As summarized by JL:

Plot makes it possible to interpolate the beta function in drifts between quadrupoles to see where beta reaches a minimum. JB would like to be able to save this table used by plot internally. For maxima this is no problem because the maximum always occurs in a quadrupole, and in between them the curve is always parabolic with positive curvature.

---

2012-01-20 11:34:10: @ldeniau set resolution to unresolved

---

2012-01-20 11:34:10: @ldeniau changed status from new to closed

---

2012-01-20 11:36:22: @ldeniau edited the issue description

Wrong argument type passed to mtlmdl (Fortran)

Issue migrated from trac ticket # 12

component: _build | priority: major | resolution: fixed

---

2012-01-19 10:56:43: jl nougaret commented

date: 2009.04.03
The 11th argument of the C call to mtlmdf has wrong type, which causes a warning at compilation. The program can however link and run.

---

2012-01-19 10:57:14: @ldeniau commented

Variable w_ipvt was incorrectly specified as integer in the function mtlmdf in match.f90 line 264 but actually it is used as double.

---

2012-01-19 10:57:14: @ldeniau set resolution to fixed

---

2012-01-19 10:57:14: @ldeniau changed status from new to closed

Make a script to update aperture tolerance files

Issue migrated from trac ticket # 21

component: _tools | priority: major | resolution: fixed

---

2012-01-19 17:55:53: jl nougaret commented

date: 2009.07.03
create a script to update aperture tolerance files according to measured profiles and standard tolerances.

Script #1
Aim: manipulate aperture tolerance file (aper_tol.b*.madx in the optics database) and measured profile files (lhc_mech_axis_shifts-b.madx under ~giovanno/aperture/V6.503/Per_data). The syntax of the profile files is described under the Aperture module page of the MAD-X manual.
Input files: aper_tol.b*.madx, lhc_mech_axis*.madx
Output files: two new aper_tol.b* versions
V1: each element in aper_tol with a measured profile will have the tolerances replaced by standard ones (see LHC Project report 1007, Table 2).
V2: each element in aper_tol with a measured profile will have the tolerances replaced by standard ones (see LHC Project report 1007, Table 2) plus max{x_i, I over measured points} (horizontal tolerance) or max{u_i, I over measured points} (vertical tolerance).

---

2012-01-19 17:56:18: @ldeniau commented

apertol.py available under ~nougaret/public/apertol.py

---

2012-01-19 17:56:18: @ldeniau changed component from _build to _tools

---

2012-01-19 17:56:18: @ldeniau set resolution to fixed

---

2012-01-19 17:56:18: @ldeniau changed status from new to closed

---

2012-01-19 17:56:56: @ldeniau changed title from script to update aperture tolerance files to Make a script to update aperture tolerance files

Homogenize MAD-X online documentation

Issue migrated from trac ticket # 31

component: _doc | priority: major | resolution: wontfix

---

2012-01-20 10:27:08: jl nougaret commented

date: 2009.07.10
Current MAD-X online documentation relies on a mixture of Latex and HTML documents. The latest documents rely on a CSS stylesheet but mix HTML markup language and contents.

---

2012-01-20 10:28:05: @ldeniau commented

2009.07.10
Proposed to harness the DITA standard to split contents and structure.
A prototype web site was demonstrated.

2009.07.10
it was decided to stick with the current documentation.

2009.07.10
the decision is to stick with the old approach.

---

2012-01-20 10:28:05: @ldeniau set resolution to wontfix

---

2012-01-20 10:28:05: @ldeniau changed status from new to closed