PENTrack

[dougUCN]

PENTrack can now import any magnetic vector field text file with 6 columns: x y z Bx By Bz (Lines beginning with % or # will be skipped. Columns may be delineated by space, comma, or tab) Units for these files are assumed to be in meters and tesla, though unit conversions can be edited in comsolField3D.h

I have also added two additional analytic magnetic fields The first one is a decaying exponential field in the x direction

ExponentialFieldX: B_x = a1 exp(- a2 x + a3) + c1 B_y = y a1 a2 / 2 exp(- a2 x + a3) + c2 B_z = z a1 a2 / 2 exp(- a2 x + a3) + c2

The second is a linear magnetic field in the z direction LinearFieldZ: B_z = a1*x + a2

See test/guideTest/config.in and test/comsolTest/config.in for more details

[wschreyer]

I finally found some time to work on your suggestions. I was planning to implement a general 3D-table field using boost::multi_array. Based on that we can write parsing routines for different file types much easier. I tried to convert your COMSOL example to that new code. But it seems like it has a 15x15x15 grid but does not contain field data for all grid points. I guess in your code those would just default to 0 field. Is that what you intended?

[dougUCN]

The comsol example only gives a sphere of data points, yeah. My code defaults stuff outside of it to 0. I kept the field folding functions in but I didn't test if it would work out.

Best, Doug

On Mon, Aug 13, 2018, 6:01 PM Wolfgang Schreyer notifications@github.com wrote:

I finally found some time to work on your suggestions. I was planning to implement a general 3D-table field using boost::multi_array. Based on that we can write parsing routines for different file types much easier. I tried to convert your COMSOL example to that new code. But it seems like it has a 15x15x15 grid but does not contain field data for all grid points. I guess in your code those would just default to 0 field. Is that what you intended?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/wschreyer/PENTrack/pull/47#issuecomment-412706503, or mute the thread https://github.com/notifications/unsubscribe-auth/ANDkXwE9keOu0_2OS1iMeHe-xTEAXJuKks5uQhNbgaJpZM4VJ1Or .

[wschreyer]

I merged your changes with my work on the new 3D-table fields, see the branch newfields. In my tests the new 3D fields look OK, but maybe you could run your tests as well and let me know if they work out? Their description doesn't really say what you expect the result to be, so it's not clear to me how to interpret them.

[dougUCN]

Apologies for the delay. As I was compiling the branch I came across a couple compiler warnings

PENTrack/src/field_3d.cpp: In function ‘std::unique_ptr ReadOperaField3(const string&)’: /N/u/dkwong/Carbonate/PENTrackTest/PENTrack/src/field_3d.cpp:94:5: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation] for (auto &xi: xyzTab) ^~~ PENTrack/src/field_3d.cpp:97:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’ if (line.find("BX") != std::string::npos){ ^~ PENTrack/src/field_3d.cpp:158:5: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] if (i != xlylzl) ^~ PENTrack/src/field_3d.cpp:160:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’ FIN.close();

[dougUCN]

Also, running the code with sim type 4, and trying to plot BFcut.out with graphstuff.py triggers the error ("Error: not an equal number of xyz coords and b field values"). I don't quite understand what indexing system you're trying to do here

[wschreyer]

I removed a spurious line break in the BFCut output. I thought I had adapted your graphstuff script, but apparently I missed it. With some fixes (e66e810bf83e5321724dbb5343b2aa722d2be003) I was able to run the test with both simtype 1 and 4, but still don't know if the output is what you expect. Maybe you could have another look?

[dougUCN]

Ah nice change to the spin integration output. I was wondering if initializing a new state y just to print would have been unnecessary, but definitely more unreadable the way I had it.

So the comsol field printout looks good but the neutron spin output is not. The helmholtz coil should be outputting a relatively uniform B field along the y axis, and the neutron spin vector should be precessing about it (attached is output from my code)

But for some reason what you have is giving something weird?

[dougUCN]

Also, I would delete the guideTest, guideTest2, guideTest3, and Ramsey2 folders. They were just tests for my own understanding on importing stl files, etc. etc.

Edit: also the Readme should be updated to include the expected output, as you pointed out

[wschreyer]

The python script was plotting the newly added spatial coordinates, not the spin vector. I guess it was not updated after adding the coordinates?

[dougUCN]

OH that's right. Haha that makes sense now. I've changed a lot of my plotting code, my master is currently quite outdated, I will be rebasing it shortly. I guess you can close this pull request!

On Mon, Oct 8, 2018 at 8:59 PM Wolfgang Schreyer notifications@github.com wrote:

The python script was plotting the newly added spatial coordinates, not the spin vector. I guess it was not updated after adding the coordinates?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/wschreyer/PENTrack/pull/47#issuecomment-428025116, or mute the thread https://github.com/notifications/unsubscribe-auth/ANDkXzLsLmy4L5dMq4vEc4uj0MvS1H6wks5ui_TcgaJpZM4VJ1Or .