Peter Willendrup

The attached monitor_nd-lib.c prints detector IDs as `long long unsigned int %llu` instead of scientific notation `%g` [monitor_nd-lib.c.txt](https://github.com/McStasMcXtrace/McCode/files/12869723/monitor_nd-lib.c.txt)

As a side note, mcrun works OK in this respect, so a solution for better handling of these instrument par=value pairs may be found there

@Rohit-Raut thank you for reaching out. Even though the segfault at first glance seems to occur in the PowderN component, it is not guaranteed that this is the actual location...

(One thing that comes to mind already is of course that you have a VERY large powder can of radius 5m, height 10, is this intended?)

The `Test_TOFRes_sample.instr` instrument has received a documentation header in this main branch commit: be00e4b5c And even though McStas 2.x is bordering "unsupported", the `TOFRes_sample` and the same instrument can be...

Unless I hear loud noises, I deem this "ready for release"

In McXtrace, the current test output looks like this through conda/cl.exe: https://tmp.mcxtrace.org/3.4.24_Windows.html a grep command for errors here: https://tmp.mcxtrace.org/errors.txt Initial indications are that (at least) this list of instruments is...

For component-driven `USERVARS`, see the example provided in `Res_sample.comp`: ``` ... USERVARS %{ double res_pi; double res_ki_x; double res_ki_y; double res_ki_z; double res_kf_x; double res_kf_y; double res_kf_z; double res_rx; double...

@anicecloud thank you, I have just inspected the data dir - I confirm this is the case, and that is of course not right! I noticed on the other hand...

So @ebknudsen I take it copying `H2O_cold.txt` over `H2O.txt` and adding a header to both indicating "water at ambient temperature" would be a reasonable correction?