snirf icon indicating copy to clipboard operation
snirf copied to clipboard

No 2D or 3D consistency required in the sourcePos-detectorPos pair specifications

Open HanBnrd opened this issue 9 months ago • 2 comments

Also related to this, I think that nothing prevents from having for example only sourcePos3D and detectorPos2D (i.e. one is 2D and the other 3D) based on current notations, could that be an issue? That would make a new symbol requiring presence if another field is present even more necessary.

|         `sourcePos2D`                 | * Source 2-D positions in `LengthUnit`       | `[[<f>,...]]`*¹|
|         `sourcePos3D`                 | * Source 3-D positions in `LengthUnit`       | `[[<f>,...]]`*¹|
|         `detectorPos2D`               | * Detector 2-D positions in `LengthUnit`     | `[[<f>,...]]`*²|
|         `detectorPos3D`               | * Detector 3-D positions in `LengthUnit`     | `[[<f>,...]]`*²|

 `*ⁿ` in the last column indicates that at least one of the subfields in the subgroup identified by `n` is required

Originally posted by @HanBnrd in #163

HanBnrd avatar Mar 14 '25 18:03 HanBnrd

Hi.

I was recently checking the validator (https://github.com/BUNPC/pysnirf2/pull/54) and it seems that the constraint is already included in the validator. Currently, a file will be valid if either (1) sourcePos2D and detectorPos2D are present or (2) sourcePos3D and detectorPos3D are present.

I am wondering if we need to include a new symbol for that or if we should include a sentence to clarify that if sourcePos2D is present, then detectorPos2D should also be. in practice, i dont really expect to see file having detectorPos2D but not sourcePos2D or a weird combination of sourcePos2D and detectorPos3D, as it would not make any sense.

Overall, I am afraid that adding too many symbols might make the specification harder to read.

Edouard2laire avatar Jun 09 '25 15:06 Edouard2laire

Hi @Edouard2laire! Yes this is correct, the validator is already checking this. And I saw you also created a PR to prevent some warnings that shouldn't happen, which is great!

The validator is not actually using symbols from the specs, and all the conditions need to be hard-coded. It would be good indeed to chat at the next meeting about what symbols we feel are required going forward.

HanBnrd avatar Jun 10 '25 23:06 HanBnrd