adouge/solensim

Solenoid simulation project

solensim's Issues

Andrii's work integration

Add structure to how you interact with the repo, since we intend to finish this shit together.

Поставь teamviewer, на след неделе подключим тебе гит нормально. Пока еще нет интерфейса к твоему коду, так что просто организованно тут лежать будет; полезно использовать орг возможности платформы. Потом, как прогресс по направлению бечелорарбайта будет, будем рассматривать интеграцию.

Todo для меня:

• /mcode/ dir
• git setup (teamviewer)
• github workflow crashcourse

Modular model "plugin" structure

Have selectable models use common interface and core backend;

ASTRA Interface Concept

use f90nml for manipulating namelists.

Desired functionality (WIP):

• run file (solenoids + source only) manipulation/creation (from "default")
• distro setup manipulation (from default)
• free field choice, via .dat files (creatable on-the-fly)
• Run generator via interface
• run ASTRA via interface
• load (& store) resulting output (pandas)

Eventuell:

• acess ASTRA's loop controls?

---

Mostly basic commands; track module should organize the API provided here for higher-level subroutines

To close:

Final Version (c)

Doc / Unified helptext format

Sections:

• general options
• main routines
• Auflistung nach Gruppen

Wrong momentum formula used

p = sqrt(2m*(E-mc^2)), applicable for v << c,
whereas the relativistic general energy-momentum relation is to be used
https://en.wikipedia.org/wiki/Energy%E2%80%93momentum_relation

Module interaction concept

Choose a way of communication between various functionality groups.

An "interface" object carrying all the data in it might be too complex to make it the defauklt way; the python workspace should be utilized more

Documentation

Future - document the software, comment code

ASTRA Plugin / Future features

• save / edit presets? - done
• custom "native" beam generator
  • kreuz
  • box
  • ring? better via generator
• Helptext

Track / Beam state visualization

Polar coordinates generally more useful for phasenraum-darstellungen

Plots:

• for phi-independent beams:
  • r/Pr, r/Pphi Darstellung
  • check phi dependence:
    • phi/Pr, phi/Pphi
• Felddurchgang-Cross section-Multiplot
• TODO

ASTRA Plugin / Basic Tools

• Outline relevant namelist elements - move into track

---

• namelist load/save, manipulation handle - done
• run generator from iPython, choose preset file - done
• run ASTRA from iPython, choose preset file - done
• load ASTRA's output
• load Beam information - done
• tmp field file access - done

Final structure concept

Root directory:

• solensim.py:
  • main script, initialize the interface
• demos.py: demos
• solensim directory/package:
  • wrapper.py:
    • tracking module handle (inherits TrackModule)
    • core handle (inherits calc.Core, which uses the TrackModule API)
    • storage, logging, general input/output & other wrapper utilities
  • backend package: processing functions & methods
    • core.py
      • Field calculation handles, analytical characterization
    • optim.py
      • Optimization module (TODO)
    • track.py
      • tracking functionality
  • frontend.py:
    • general interface (inherits core handle)
    • tracking functionality interface (inherits tracker handle)
    • ASTRA plugin interface - inherits the interface core
• plugins directory: well, plugins - interfaces to third software
  - astra:
  • communication with ASTRA - namelist manipulation & management, output readin
    - mcode:
  • interfaces to Octave, MATLAB engines (Andrii's work)

Numerical tracking proposal

As Jens proposed, brute force everything by simulating an electron passing through the fields?

If I understand it correctly.

Update repo

• Lint code:
  • Turning on linting brings up a shitton of errors, bad programming practice and stylistic errors + missing documentation.
• Import labels and issue org. logic from adouge/eyp-antdou

Track module concept

Aim:

• study and quantify field effects on beam via tracking

Goal:

• standalone interface
• API for field characterization in calc

Methods:

• Use structured beams to see field effects
  • cross, ring, box etc
• Sweep-type study to see effects' dependence on beam or field characteristics
• ???

Functionality demands:

• run tests, with run control - got the "run" part, need tests
• visualization & quantitative analysis of resutls - elaborate?

Plotter wrappers using decorators

Doc / Interface features requests

Expand the user-facing features

• Jupyter Notebook built on top of the iPython API
• Result storage
• Permanent global config file

Track result labeling

Running same labels adds duplicate entries to track.results instead of modifying existing entries.
--> Replace append(df) with .loc writing

Optim / Adjust scaling

The resulting scaling parameter is always almost the same as the starting one.

Possible reason: inconsistent scaling of parameters, i.e. o(geometry) = 10^(-3), o(N*I) = 10^3

Possible fix: have the algorithm optimize in normalized parameters

Reconsider Rsq/c opt mode

For better wide-interval optimization.
Then, from optimal rsq/c, different configurations can be proposed.

Need to fix presentation

TODO: Presentation:

0. Project formulation, motivation (TODO: rewrite)
1. Necessary theory beyond basics: (TODO: condense, remove redundant)
2. Project methodology: (TODO: Rewrite)
   1. Model recap (TODO: avoid unneccessary redundancy & repetitions!!!)
   2. Algorithm:
      1. General schematic
      2. Optimization, briefly
3. Software presentation: (TODO: Rewrite completely)
   1. General structure
   2. Interface
   3. Example output - compare to calc
   4. Example design study - tradeoffs (TODO: more different examples)
4. Conclusions:
   1. Further development - pitch ideas
   2. Summary (Rewrite!)

Yoke model

Self-explanatory.
Expand model to add a yoke

Feature / Logger feature

• Permanently store optimization results
• Load results, "labels"?

Visualization features list

Updated 28.08.20:

Visualization features thread

• ???

Optim / Dynamic convergence tolerance

xtol, gtol, ptol are starting to make a difference. They should be dynamically adjusted based on the problem's conditions and desired level of precision.

Calculated focal length too small

F calculation method via field integrals (from Acc101, thesis) gives f-values lower than tracking does.

Doc / License change

GPL is somewhat impractical, and there might be limitations to the end software's applicability - I doubt that every potential user would be ready to release their work incorporating solensim into the open access circulation.

AFAIK/IIRC, LGPL should avoid this limitation.

As the GNU site says, releasing software with non-unique functionality under GPL is impractical.
solensim is, in that sense, not too unique - it is merely an interface over other fieldsim / tracking software.
But - I'm not sure about the design optimization part. If that would turn out to be unique...
We'll see. That is a question for later.

wrap.stop(engine) not working

More flexible geometry constraints

E.g. have the minimum internal radius not dependent on beam radius, but a separate constraint parameter

Calc / Need chrom aberrations

Optimizing for cs is unreasonable;
calculated spot sizes are 3-4 orders of magnitude below the PROTON RADIUS, i.e. irrelevant.
Chromatic aberrations are what we should consider.

ASTRA & high zphase settings

There's a limitation on how many output files ASTRA is willing to generate, placing a cap on relative step size.
It's an issue for future development, irrelevant to current tasks, so goes here.

Solution:

• use try-catch loop to dynamically increase step until ASTRA runs? places a limit on precision for fields with high aberration (since this is mostly relevant for focal sweeps).
• an alternative would be to split the swept region into multiple runs, running ASTRA in segments, and then amalgamating the data. Arbitrary precision would be possible.
  • The necessity of such an undertaking will be determined by whether "effective focus" "measurement" would provide enough information & accuracy to substitute for focal region analysis.

Feature / Permanent workspace

Take #20 further - have an option to save current work state, as in separate "projects", to continue at an arbitrary time later.

Track / Trajectory visualization

Use trajectory probe particles from phi-independent distributions to draw a "sideways"-view of the field

• approximate focal point
• "brechung" at "lens plane" visualization

--> need a phi-independent, 2D, non-monochromatic distribution, with symmetrical sets of monochrome particles at various radial distances:

• multiple "rings" to show spherical aberration - the cross does that already
• different energies within same ring to show chromatic aberration - got this

--> need validation from Jens on this
--> need customized distributions

Track / ASTRA output study

Was sagt mir eigentlich die ASTRA?

Direct input to field description subroutines

Doc / Repo format

• dependency list / manifest file
• readme expansion

ASTRA Plugin / Complete Package

TBA, finish implementing #37, what wasn't done in #40

ASTRA Plugin / Default preset

• Default runfile - REGAE solenoid, w/ screens - done
• default distro generation - ??????

Calc / Fieldsim options

Native:

• twoloop
  -_ ????_

External:

• Superfish via Docker

Doc / Software documentation

Comment code w/ docstrings, helptexts:

• Frontend: helptexts:
  • Astra Interface - done
  • Core interface
• Backend:
  • calc: docstrings!
  • track: docstrings!
  • optim: docstrings!
• Demos: descriptions, docstrings
• Main script: Anleitung/"helptext"!
  • to readme.txt
• Wrapper: docstrings
• Plugins:
  • Astra: docstrings! - done? - helptext is descriptive enough?

---

Documentation:

needs planning

• keep separate from "theoretical" docs? too far off to tell.

Optimize focal spot size instead of cs

Since the spot size is not directly prop to cs, and there are cases where f is higher for lower cs.

Improve efficiency

various descriptive methods (get_l, max B, f etc.) rerun field integrals; each field integral calls on Bz, multiple times (F3 calls once for B, second time for num differentiation to 2nd order)
--> too many field calculations;

with a more complicated model, it will slow down to a crawl.

Need to restructure backend.