- Indico style
- Indico style - inline minutes
- Indico style - numbered
- Indico style - numbered + minutes
- Indico Weeks View
Taking decisions on main code brances (which are to be followed, which are to be used for e.g. parallelisation or certain validation cases) and upcomming master release.
10-15 min talk + questions/discussion
(20+20)min. Patrick's slides will be presented by Yannick
Points raised during the session:
- Simulation model in Eiron same general idea as EIRENE, but some unclear things (Dmitriy)
- Grid representation is important, unstructured grids (Yannick, Dmitriy)
- For the domain decomposition solution: have you done a proper literature review on similar solutions? (Yannick) [Oskar: no I haven't, good point]
- There are time pressure concerns, how quickly will Eiron be ready for some type of publication/release? (Yannick, Dmitriy) [Oskar: One estimate is a year from now, but that is a very very rough estimate]
- Dmitriy: a publication would be very important
(Including in a view of IMAS)
Photon tracing
ModCR
25+20 min
Yanick, Xavier, Derek, Dmitriy B.
Emil:
(25+15min)
Next steps for Niels:
Emil:
(25+15min)
Status incl. J.Gonzalez work + own view
25+20 min
Decisions
Collision rates
- for MVP Eiron: use flat rate
- for general case: samples with spline interpolation is a general representation, as long as there is a possibility to use a log scale for some parts of the energy spectrum
- the runtime collision rate function can then use a single representation for the collision rate(energy) function, a preprocessing step transforms any specific fits to these samples to use in the spline interp
Trajectory representations
- for MVP Eiron: use point paths
- for EIRENE, a point path + sparse grid representation would be more efficient in certain cases, where the trajectory discretization requires a lot of checks that slow the process down, which makes storing the result worth it, despite the storage cost
- related: there are multiple neighbor-indexing solutions, EIRENE uses a neighbor list (graph array repr.), but an octree/quadtree solution could compete, is an something to think about in future projects
Grid representation
- for MVP Eiron: use cartesian 2 D grid
- for general case: the grid needs to be aligned with the magnetic field, which means that a polygonal mesh (or curved surfaces) are needed
- a polygonal mesh will be a general grid description that should work in all cases
- the walls can be a part of the polygonal mesh
- Two most used grid representations: LEVGEO=4 and LEVGEO=10, LEVGEO 4 is triangles, polygonal mesh, LEVGEO 10 is user provided geometric model, used by EMC3
(LEVGEO 5 is tetrahedrons, which would be the 3D case)
Estimates
- Particle density, momentum density, and event density is enough to calculate all other estimates
- Mean + variance is also enough, although a range (max,min) could be useful
- note: it should not be too difficult to add additional statistics accumulators to the estimates, so this should be a non-issue
Other comments
Domain decomposition (Dmitriy, Yannick):
Extra: Idea for handling curved surfaces (purely academic, not a serious suggestion for work)
- pretend it's straight, adjust the track length attributed in the cell by adding the error to the curved surface
- to make this accurate, you need interpolated smooth collision rates
- CON: that makes the integral more complicated
Machine description, AMNS and other data concepts
For each line of the code camp should be a summary and a proposed list of action points to be proposed and agreed during the discussion
Photon tracing module
ModCR