|
1)
Message boards :
Sixtrack Application :
Very short WU
(Message 39690)
Posted 23 Aug 2019 by  Veronica
Post: Fortran have max. 7 Dimensiones, when remember correct (Fortran77) ;-) I believe Fortran 2008, which we use, has a maximum rank of 15. In any case, 6 coordinates for our particles means that we need n x 6 of storage for n particles. So only rank 2 if we were to use a single array for it. |
|
2)
Message boards :
Sixtrack Application :
Very short WU
(Message 39475)
Posted 1 Aug 2019 by Veronica
Post: Hi Veronica, That was very symplectic of you to explain that to us. Now if I could just get my head around 6-dimensional ;-} In our case, 6 dimensions is easy. It's just the three coordinates for the current position of the particle, and three more describing the direction it's headed. :) |
|
3)
Message boards :
Sixtrack Application :
Inconclusive, valid/invalid results
(Message 39474)
Posted 1 Aug 2019 by Veronica
Post: most are waiting for a 3rd host to re-run WU and validate or not. We have seen some corner cases were simulations do behave weirdly and inconsistently. In fact, one of the test jobs Eric made once is on of those that with certain compiler configurations do produce different results in different run environments. I suspect these corner cases are simulations where multiple particles are lost, which is the case for Eric's test, and I have identified one issue that could potentially be the cause of these inconsistencies. Essentially, the particle lost flag may be read from an index outside the array where it's stored. Out-of-bounds indices can also be caused by the input file for the WU having invalid settings that are not caught by the input file parser. We've identified and fixed a few such cases in the very old parts of the code, but there may be more. Our test suite is not good at catching these as the tests tend to have valid input files. These bugs are generally discovered by our users. |
|
4)
Message boards :
Sixtrack Application :
Very short WU
(Message 38738)
Posted 7 May 2019 by Veronica
Post: From the job name it looks like the particles in that work unit have a large amplitude, so I expect they may have been lost in the simulation. When the particles are lost, the simulation stops early. The simulations we send to BOINC are usually large scans of parameters, and a certain fraction of them will tend to be very short. This is just the nature of the studies we do. |
|
5)
Message boards :
Sixtrack Application :
SixTrack v502.05 on Win XP
(Message 38734)
Posted 7 May 2019 by Veronica
Post: We don't mind supporting old systems if it's a simple fix. We have a pool of contributors running on XP, and our application has run fine on it for a long time after Microsoft stopped their support. Since it now stopped working with our recent builds, it was important for us to understand why. |
|
6)
Message boards :
Sixtrack Application :
SixTrack v502.05 on Win XP
(Message 38721)
Posted 7 May 2019 by Veronica
Post: Well there is/was XP Pro x64 Edition, released on April 25, 2005 Yes. However, the kernel call was added in Vista, so I don't think that helps. In any case, SixTrack only uses up to a couple hundred MB of memory, depending a little on which accelerator it's running simulations on. |
|
7)
Message boards :
Sixtrack Application :
SixTrack v502.05 on Win XP
(Message 38720)
Posted 7 May 2019 by Veronica
Post: An update on this issue. I went through the source code of 4 different version of gcc, and I didn't find anything that indicated the issue was there either. In the end I came across a discussion about MSYS/MINGW support for WinXP. They bumped the minimum requirement to Windows 7 in September last year. This means our build environment (runtime libraries) no longer supports Windows XP. It will likely still work on Vista though. We'll have an internal discussion what to do about this in the future. |
|
8)
Message boards :
Sixtrack Application :
SixTrack v502.05 on Win XP
(Message 38717)
Posted 7 May 2019 by Veronica
Post: Tried it on mine and it was an instant crash a second after d/l Yes, it's the same error. The problem is as stated in the OP that the kernel call to the clock tick counter does not have a 64 bit precision interface on Windows OSes before kernel 6.0 (Windows Vista). On older OSes this is bypassed in for instance zlib by taking the 32 bit value and padding it with zeros. For us, unfortunately, this does not look straight forward to fix as the libgfortran.a we link is built with WINVER >= 0x0600 by default. We use MSYS/MINGW-w64 to build SixTrack on Windows, and it comes with packages that are too new to still support pre 6.0 kernels. We did manage to build a working exec for WinXP for the 5.2.5 release because one of the guys here had an old virtual machine where the build environment had not been updated for a couple of years. That is not really a good long term solution though. |
|
9)
Message boards :
Sixtrack Application :
Memory requirement and VB vs. native
(Message 38703)
Posted 6 May 2019 by Veronica
Post: Thanks Veronica. I now have 12 GB of memory, so I think I could run Atlas tasks again when it comes back online. So does the sixtracktest application run the developer versions? SixTrack is under continuous development as new features are added regularly due to specific needs for studies being performed by the various groups at CERN that uses SixTrack. We therefore do frequent patch releases with new features on our main repository, as well as fixes and other tweaks. A lot of these releases are not intended for BOINC use, so we do specific BOINC releases whenever we need to put new features into the SixTrackTest queue. They are not developer versions per say, but when we have a version that performs well on SixTrackTest, we intend to bump it to the main queue. |
|
10)
Message boards :
Sixtrack Application :
SixTrack v502.05 on Win XP
(Message 38702)
Posted 6 May 2019 by Veronica
Post: Hi, and thanks for your error report. I am not surprised that SixTrack does not run on WinXP 32-bit. It is built on Windows 10 with a minimum Windows version compatibility of 6.0. I managed to download a WinXP SP3 VHD image from Microsoft, so I will try and tweak our build system and test it on this. The solution you posted is specifically relevant to the windows.h include file, so not sure how this relates to the Fortran side of things, if at all. But I will try and set Windows version to 5.1 for libarchive and the BOINC library as a start. |
|
11)
Message boards :
Sixtrack Application :
Memory requirement and VB vs. native
(Message 38026)
Posted 18 Feb 2019 by Veronica
Post: Exactly how much is allocated depends mostly on what accelerator description is being simulated, but also on how many particles is being tracked. The latter is usually a small number for BOINC jobs. ~300MB seems about right for SixTrack 4. SixTrack 5 generally uses less memory than older versions as memory is allocated as needed as opposed to fixed allocations in SixTrack 4. SixTrackTest should therefore in general use less memory than the production version. We will soon switch production to running on SixTrack 5. |
|
12)
Message boards :
Sixtrack Application :
multi threading six track possible in any way?
(Message 37900)
Posted 1 Feb 2019 by Veronica
Post: A bit OT, but ... Thanks! There are currently six of us maintaining and developing the code on a regular basis. We're hoping SixTrack 5 can soon go into production on BOINC. |
|
13)
Message boards :
Sixtrack Application :
SIXTRACKTEST
(Message 37892)
Posted 1 Feb 2019 by Veronica
Post: I don't understand either, cause I digged into the result with id 212498881 and found the mem_alloc file a few minutes before the task finished. Just an update: This was a debug file we used during development of SixTrack 5 when we added dynamic allocation of the large tracking arrays. This should not have gone into the BOINC executables and has been fixed in the current test execs. |
|
14)
Message boards :
Sixtrack Application :
multi threading six track possible in any way?
(Message 37889)
Posted 1 Feb 2019 by Veronica
Post: Hi, SixTrack is not a multi threaded application, and due to the nature of the simulations we run on SixTrack, there is no real need for parallelising it. |
©2024 CERN