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

Feature/integrating b solver #118

Closed

Conversation

pslocum
Copy link
Contributor

@pslocum pslocum commented Oct 1, 2024

Following a brief test with a single off-center finite wire segment defined by 2 points, I am noticing that the B-field is being calculated 3 times using Biot-Savart, and is being accumulated. This causes the output B fields to be too high by 3x. I am suggesting a possible workaround such that the accumulation is removed. However, there may be a better way to think about this. The config files that I am using are here. Thanks in advance for any thoughts.
image

nsoblath and others added 30 commits March 11, 2016 09:49
…ia from Locust. The conditions are presently global and are defined in small functions that can be dropped into the appropriate static event modifier class. Modified classes are LMCKassSignalGenerator and KSRoot.
…tronRadiationExtractor::ExecutePostStepModification().
…n thread status out of ReceivedEventStartCondition.
… KSTrajInterpolatorHermite.cxx pending more testing.
Check for Boost library as variable or imported target
nsoblath and others added 21 commits June 23, 2020 11:46
@richeldichel
Copy link
Contributor

Hi @pslocum, thanks for your message. Unfortunately, we get a 404 error for your config that you provided via the link. It would be great if you could fix this so that we can have a look.

@pslocum
Copy link
Contributor Author

pslocum commented Oct 1, 2024 via email

@richeldichel
Copy link
Contributor

Hi @pslocum, thanks for identifying this. It seems that the rod_space is added 3 times to the electromagnet container instead of just once. I am not sure at the moment, why that is the case, but your workaround is probably only applicable to the specific case where you have only one geometry element for the field calculation. I need to investigate further what happens when the container is created. Will keep you updated!

@pslocum
Copy link
Contributor Author

pslocum commented Oct 9, 2024

Hi @richeldichel, thanks for the update. And please keep me posted with any additional steps or checks that would be useful.

@richeldichel
Copy link
Contributor

I think I have found the culprit! In line 46 of your config Ioffe_V09_Activated.xml you define the following electromagnet:

<electromagnet name="electromagnet_solenoid" spaces="@ioffe_magnet_tag" current="[ioffe_current]"/>

Here you define the spaces to be used via spaces="@ioffe_magnet_tag". This definition is ambiguous in the sense that the magnet tag is contained in three (nested) spaces. Therefore, the electromagnet container contains the spaces of @ioffe_magnet_tag three times, which leads to the incorrect sum of the magnetic field. If you select e.g. spaces="project8_ioffe_assembly/@ioffe_magnet_tag", only the one space from this geometry path is included in the container and I get the correct sum.

To make this mistake more visible, I will create a PR that adds a warning when a tag is encountered in a place where a path is expected.

@pslocum
Copy link
Contributor Author

pslocum commented Oct 9, 2024

Hi @richeldichel, thank you very much for identifying this. And yes, as you point out, it will be helpful to have a warning when the full geometry path is needed instead of just the tag. Thanks again!

@richeldichel
Copy link
Contributor

Closing this in favor of #119

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants