-
Notifications
You must be signed in to change notification settings - Fork 51
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
Introduce arbitrary orientation for lumped ports #75
Introduce arbitrary orientation for lumped ports #75
Conversation
4ef850e
to
5c195ec
Compare
Reverting to draft after discussion about bug in the bounding box length calculation. |
5c195ec
to
0016dfb
Compare
ae7b253
to
6e8c8fc
Compare
6e8c8fc
to
e9ea850
Compare
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.
Cool stuff! Thanks @hughcars.
e9ea850
to
4855f20
Compare
e042081
to
1f611a9
Compare
2311224
to
51a930d
Compare
I've pushed a branch sjg/lumped-port-orientation-fixes which contains some final fixes (almost all style/formatting) to this branch. If it looks good to you, feel free to merge it here before this ready for merge (following #75 on which it is based). |
452ba2f
to
8a1aebf
Compare
* Both make use of a reduce/gather paradigm to compute bounding boxes/balls for a collection of points. Given this, they do not scale well with growing ranks. They are however capable of handling arbitrary orientation of two dimensional ports. * The algorithms rely on sorting tricks applied to containers of the vertices * The uniform lumped port was tested by applying a 30 degree rotation about all three axes to all the vertices of the rings mesh. * The uniform lumped port also performs an axis snapping for user specified direction vectors, this means the resulting calculations are forgiving on precision issues. * Calculations were tested by applying rotations to the global mesh and checking that the resulting areas agree with the integrated values
…tes from a discovered axis, rather than snap to axis
…0,1). - Most of the values are perturbed only on the 3rd sf or so. - For the probe data, it is necessary to apply the axis angle transformation on the original data - In julia: ``` julia> AngleAxis(pi/3, 0,0,1) * [-6.975740032e-01, -3.331547360e+00, +1.022439079e+02] 3-element StaticArraysCore.SVector{3, Float64} with indices SOneTo(3): 2.5364176460709804 -2.269890487790808 102.2439079 julia> AngleAxis(pi/3, 0,0,1) * [-2.108257694e-03, -1.094675073e-02, +1.007018922e+01] 3-element StaticArraysCore.SVector{3, Float64} with indices SOneTo(3): 0.008426035374075847 -0.007299180085728002 10.07018922 ``` which agree fairly closely with the newly generated values ``` i, B_x[1], B_y[1], B_z[1] 1.000000e+00, -2.744244415e+00, +2.362252272e+00, +1.021127464e+02 2.000000e+00, -8.553328102e-03, +7.180956729e-03, +1.007140281e+01 ```
… with theta = 0.0
- All the non-probe data is very close to the original values, modulo a few sf - The probe data requires a transformation of the rebaselined data: ``` julia> Ref(AngleAxis(pi/6, 0,0,1)) .* [[-1.934600007e+00, +1.332005966e+00, +1.007689041e+02], [-2.056769746e-03, +3.073509047e-03, +1.007227123e+01]] 2-element Vector{StaticArraysCore.SVector{3, Float64}}: [-2.3414157352235527, 0.18625100104843154, 100.7689041] [-0.0033179693732712672, 0.0016333520404633007, 10.07227123] ``` which compares to ``` i, B_x[1], B_y[1], B_z[1] 1.000000e+00, -2.471968830e+00, +3.021551217e-01, +1.012769086e+02 2.000000e+00, -7.789873394e-03, +1.048294735e-03, +1.006816729e+01 ``` the additional discrepancy can be partially attributed to breaking of rotational symmetry, as the axis does not pass through a vertex of the bounding box of the domain. Better agreement can be found with pi/3 around (1,1,1), but (0,0,1) is chosen for ease of understanding in the examples. Note: the data was generated on a mac M1 with a tighter tolerance of 1e-9, as this was required to reduce discrepancy in the values of the second probe and to agree with CI.
- Update schema to account for CoordinateSystem - Fix bugs with config parsing and update some more config files - Refactor point cloud calculations to reduce duplication and hide local functions
…s' into hughcars/lumped-port-orientation-dev
…nd comments and allowing GlobalMinLoc/MaxLoc to use arbitrary type for the second argument as supported by the available MPI types
…for maximally separated points to define initial diagonal/diameter
f632ee9
to
b9c26d7
Compare
@hughcars, I've rebased this on |
Looks good, slight change to the comment wording, and two missing |
Description of changes:
[x,y,z]
, in addition to the existing key word"X"
,"-Y"
,"+R"
style interface.BoundingBox
andBoundingBall
. These work by reducing onto the dominant rank all data associated with a marked portion of the mesh, then applying sorting/separation approaches based on a a highly restricted subset of the QuickHull algorithm.Nuances:
lumpedelement.hpp
is to decide upon a length/width of a rectangular port, and outer radius of a coaxial port."+R"
direction in a coaxial port is non ambiguous, however the specification of circumferential or azimuthal forcing would be ambiguous. This ambiguity was not resolved, as at present neither of these forcing types have been needed.Issue #, if available:
Closes #71