-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1D tally maps #122
1D tally maps #122
Conversation
do i = 1, self % N | ||
! Print lower bin boundary | ||
call out % addValue(self % bounds % bin(i) + PI) | ||
|
||
! Print upper bin boundar | ||
call out % addValue(self % bounds % bin(i + 1) + PI) | ||
end do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do i = 1, self % N | |
! Print lower bin boundary | |
call out % addValue(self % bounds % bin(i) + PI) | |
! Print upper bin boundar | |
call out % addValue(self % bounds % bin(i + 1) + PI) | |
end do | |
do i = 1, self % N | |
! Print lower bin boundary | |
call out % addValue(self % bounds % bin(i)) | |
! Print upper bin boundar | |
call out % addValue(self % bounds % bin(i + 1)) | |
end do |
NOTE: otherwise the bins don't coincide with the bins of the results.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lines 379 - 382: also remove PI from the printed bin values
One question before I dive in: would it be neater to have a generic radial map where you can specify which dimensions/plane/axis to account for? For example, it could be xy, xz, yz, or xyz (spherical). This is as opposed to having separate cylindrical and spherical radial maps. |
Yes that should be easy enough! Let me give it a quick try. |
@@ -0,0 +1,153 @@ | |||
module directionMap_test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps more descriptively it should be azimuthalDirectionMap or something similar? This would be to distinguish it from an eventual polar direction map.
@@ -0,0 +1,194 @@ | |||
module directionMap_class |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Meant to put that previous comment here...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No worries, I understood! It's a bit of a long name. I personally would leave it as it is until a polarMap comes by. Also because you can map direction on any plane with this, so it's quite general.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Going from -pi to pi it is still the azimuthal component of direction, which is not inherent to any plane. I would suggest it's better to rename it in advance of having polar because it is more descriptive and helps us not forget. Even something like azimuthDirMap.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case, it might be even more convenient to leave it generic and add the possibility to modify the angle range to anything within -PI to PI. So one could tally -PI to PI on a plane and 0 to PI on another
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose it would still be a fraction of the azimuthal plane. Wouldn't the polar equivalent need some weighting by a sine? But, in principle, the range could be limited. I imagine that might make things a bit messier and also wouldn't be requested very frequently so I wouldn't worry much about it.
One more thing: which direction would the 0 angle correspond to in a given plane? Or pi/2? It would be good to mention these explicitly at least in the comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that if you want to integrate over a polar angle you need to add the sign weighting as a Response, rather than in the tally Map. Now I added a custom min and max angle, so that it generalises better.
self % DIM2 = Y_AXIS | ||
|
||
case default | ||
call fatalError(Here, 'Keyword orientation must be x, y or z. It is: '//type) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This or the cases would need to change.
spherical = .true. | ||
|
||
case default | ||
call fatalError(Here, 'Keyword orientation must be x, y, z or nothing for spherical. It is: '//type) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This error is inconsistent with the spherical case above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would add it might be good idea to include xyz
keyword in the doc comment. As suggested above
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me with just couple of minor issues.
Thanks for the addition!
!! | ||
!! Maps the particle direction in linear bins in the range 0-360 degrees | ||
!! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this description is not up to date. The maps works in -pi pi range in radians, right?
We should also mention with respect to what the angle is measured and highlight that user can specify the plane?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it was. Now I changed it to be defined in degrees from -180 to 180, given that degrees are more intuitive I think. I added those comments.
spherical = .true. | ||
|
||
case default | ||
call fatalError(Here, 'Keyword orientation must be x, y, z or nothing for spherical. It is: '//type) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would add it might be good idea to include xyz
keyword in the doc comment. As suggested above
!! Sample Dictionary Input: | ||
!! radialMap { | ||
!! type radialMap; | ||
!! axis x; // Optional. Default is spherical map |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
!! axis x; // Optional. Default is spherical map | |
!! axis x; // Optional. Default is 'xyz' (spherical map) |
! Check & load origin | ||
if (spherical) then | ||
call dict % getOrDefault(self % origin, 'origin', [ZERO, ZERO, ZERO]) | ||
else | ||
call dict % getOrDefault(self % origin, 'origin', [ZERO, ZERO]) | ||
end if |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should check the size of the origin
? I am not sure if it is done.
Also perhaps we should always use all 3 coordinates? Origin is a point in space, one coordinate will be redundant, sure, but I know I will be getting confused about what are the axis if we switch two two only for cylinders ;-) [Basically like it is done for cylindrical surfaces]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess I was imitating what done in cylinderMap, where the origin only had two entries. I am changing both cylinderMap and radialMap to read origins with 3 entries to avoid confusion for the user.
! Calculate the distance from the origin | ||
r = norm2(state % r(self % axis) - self % origin) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
! Calculate the distance from the origin | |
r = norm2(state % r(self % axis) - self % origin) | |
! Calculate the distance from the origin | |
r = norm2(state % r(self % axis) - self % origin(self % axis)) |
Assuming that we are using size 3 origin.
I'll ho ahead and merge this, given that it was approved and only a couple of aesthetic things changed since! |
Just tidying the maps a bit: if we want to keep the separation between tallyMaps and tallyMaps1D, which is useful for the multiMaps, I think some order makes things clearer.
The main changes are:
I forgot to update the User manual, I'll do it after the reviews to make sure I am not missing anything given that a lot has to be changed.