Skip to content

SIMPLE to sample uniformly in s between sbeg(1) and sbeg(2) if num_surf=2#44

Closed
jlion-pf wants to merge 2 commits into
itpplasma:mainfrom
jlion-pf:sample-uniformly-in-s-if-num_surf-2
Closed

SIMPLE to sample uniformly in s between sbeg(1) and sbeg(2) if num_surf=2#44
jlion-pf wants to merge 2 commits into
itpplasma:mainfrom
jlion-pf:sample-uniformly-in-s-if-num_surf-2

Conversation

@jlion-pf
Copy link
Copy Markdown

With this change, SIMPLE will start to uniformly sample between sbeg(1) and sbeg(2) if the user provides num_surf=2 in the input file.

Happy to discuss different implementation of this feature @krystophny

@krystophny
Copy link
Copy Markdown
Member

krystophny commented Feb 21, 2024

Thanks @jlion-pf and sorry for the late response. I see the intent and would prefer to solve this in an even more general way as follows:

Re-introduce a switch local = .True./.False. that decides to start the orbits locally, or distribute them globally. If size(sbeg) <= 1, local=.False. means sampling between s=0 and s=1. If size(sbeg) >= 2 it should sample between the smallest and largest s for local=.False.. For local=.True. we just want sampling on our list of s and crash if size(s)<1.

Really clean alternative: Introduce an abstract class or subroutine interface that allows multiple samplers, e.g. LocalSampler and GlobalSampler or sample_local, sample_global. Select the concrete sampler instance via the config file and have a specific block with different options for each realization (list of surfaces for local, start and end surface for global).

What do you think? Do you have capacity to do that? Or @dannythecore ? Otherwise it could take a while for myself.

Best
Chris

@krystophny
Copy link
Copy Markdown
Member

This works now with startmode=5 and setting two flux surfaces sbeg(1) and sbeg(2).

@krystophny krystophny closed this Mar 18, 2025
krystophny added a commit that referenced this pull request May 22, 2026
## Summary

Follow-up to #323. The squash-merged classification fix means main now
matches the output that this branch's `simple.x` produces for
`golden_record_classifier_fast`, so the temporary
`GOLDEN_RECORD_SKIP_CASES=classifier_fast` escape hatch added in #323
can be removed.

Two small changes:

1. `test/tests/CMakeLists.txt`: drop
`GOLDEN_RECORD_SKIP_CASES=classifier_fast`
   from the per-test ENVIRONMENT. The `SKIP_CASES` plumbing in
   `compare_golden_results.sh` stays in place for future
   intentional-divergence bug fixes (just don't set the env var
   unless a fix needs it).
2. `test/golden_record/compare_golden_results.sh`: drop
   `avg_inverse_t_lost.dat` from the classifier file list. That file is
   only written when at least one particle is actually lost; with the
   fast_class fix the small `classifier_fast` test loses zero particles,
   so neither ref nor cur writes it. The comparator's "reference file
   missing" check then spuriously fails even though both runs agree
   byte-for-byte on the files that do exist.

## Verification

Full regression suite, against freshly rebuilt main reference (cached
`runs/run_main` and `simple_main` rebuilt to pick up #323):

```
$ make test-regression
...
13/13 Test #50: golden_record_sanity ....................   Passed    0.57 sec
100% tests passed, 0 tests failed out of 13
Total Test time (real) = 411.09 sec
```

Both classifier cases:

```
1/1 Test #45: golden_record_classifier_fast ...   Passed   16.73 sec
1/1 Test #44: golden_record_classifier_combined ...   Passed   16.18 sec
```

## Test plan

- [x] `make test-regression` passes 13/13 locally
- [x] `golden_record_classifier_fast` (the test #323 had to skip) passes
- [x] `golden_record_classifier_combined` (new in #323) still passes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants