Skip to content
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

Part Wire needs a specific ordering to reconstruct wire using deserialise_shape #3037

Open
OceanNuclear opened this issue Feb 22, 2024 · 4 comments · May be fixed by #3095
Open

Part Wire needs a specific ordering to reconstruct wire using deserialise_shape #3037

OceanNuclear opened this issue Feb 22, 2024 · 4 comments · May be fixed by #3095
Assignees
Labels
bug Something isn't working cad Tasks relating to the cad module codes Tasks relating to integration of external codes

Comments

@OceanNuclear
Copy link
Contributor

OceanNuclear commented Feb 22, 2024

Expected behaviour

Start point == start point of the first edge,
end point == end point of the last edge.
i.e.
BluemiraWire.start_point() == BluemiraWire.edges[0].start_point()
BluemiraWire.end_point() == BluemiraWire.edges[-1].end_point

Actual behaviour

Start point == start point of the LAST edge,
end point == end point of the FIRST edge.
i.e.
BluemiraWire.start_point() == BluemiraWire.edges[0].start_point()
BluemiraWire.end_point() == BluemiraWire.edges[-1].end_point

Example/Steps to reproduce

Loading the divertor face wire to examine.

Screenshots / Tracebacks

image
image
image
image

Explanation

This is because BluemiraWire.shape.Edges is sorted in reverse order, for reasons unclear to me.

Proposed solution

In _freecadapi::start_point and _freecadapi::end_point, Wrap the obj.Edges inside the Part.sortEdges function (and then unpack by indexing to [0]), before indexing to [0] and [-1] as before, respectively.

Note

I guess this means freecad's API uses memory in a weird/unpythonic way where lists are not ordered by default?

@OceanNuclear OceanNuclear added bug Something isn't working cad Tasks relating to the cad module codes Tasks relating to integration of external codes labels Feb 22, 2024
@OceanNuclear OceanNuclear changed the title start and end points of bluemirawire ordering are messed up start and end points of bluemirawire aren't reliable Feb 22, 2024
@OceanNuclear
Copy link
Contributor Author

This underlying issue seems to also plague BluemiraWire.value_at. It's worth looking into the example file I've provided.

Or it could be an issue with deserialize_shape/serialize_shape.

@je-cook
Copy link
Contributor

je-cook commented Mar 4, 2024

There is also shape.OrderedEdges. either way on the whole you shouldn't have to use any freecad api to do this

@je-cook
Copy link
Contributor

je-cook commented Mar 4, 2024

I would also wager it may come from deserialising the wire

@je-cook je-cook changed the title start and end points of bluemirawire aren't reliable Part Wire needs a specific ordering to reconstruct wire using deserialise_shape Mar 6, 2024
@je-cook
Copy link
Contributor

je-cook commented Mar 6, 2024

After looking into this it seems like all the edges are reconstructed correctly by the deserialiser but when combined the shape created is not as expected. This could be down to a number of things but my guess is that it may be effected by #1347 and will be very hard to isolate until that is closed.

For now there is nothing particular that can be done to improve the situation other than to note that serialise_shape and deserialise_shape should be used with caution. The serialiser seems to produce what its expected however

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working cad Tasks relating to the cad module codes Tasks relating to integration of external codes
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants