by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 15 2019 18:21
    cophus commented #2
  • Sep 15 2019 18:18
    cophus commented #4
  • Sep 04 2019 21:20
    thomasaarholt opened #4
  • Aug 29 2019 08:21
    thomasaarholt closed #1
  • Aug 29 2019 08:21
    thomasaarholt commented #1
  • Aug 29 2019 08:20
    thomasaarholt commented #2
  • Aug 29 2019 08:06
    thomasaarholt closed #3
  • Aug 29 2019 08:06
    thomasaarholt commented #3
  • Aug 29 2019 08:06
    thomasaarholt commented #3
  • Aug 28 2019 17:18
    cophus commented #2
  • Aug 28 2019 17:13
    cophus commented #1
  • Aug 28 2019 17:05
    cophus commented #3
  • Aug 27 2019 07:32
    thomasaarholt opened #3
Colin Ophus
@cophus
@zhantaochen Sorry for the delay in following up - been quite busy this week! Here are several matlab scripts, and the output files I made for the SuperSTEM tutorial on www.prism-em.com
In rotateCell01.m, you can see how I rotate and re-project rational approximations of the barium neodymium titante cell - for example you could un-comment different blocks like:
% % % [0 1 2] zone axis
% UCtile = [1 11 1];
% xProj = [1 0 0];
% yProj = [0 5 1];
% zProj = [0 1 -2];
@zhantaochen If this isn't clear, I can make a simple 2D graphene example for you too - re-projecting the primitive cell with 120 degrees between lattice vectors to a 90 degree corner [1 sqrt(3)] a cell just requires using projection vectors like [1 0] and [-0.5 0.5 sqrt(3)]
zhantaochen
@zhantaochen
Thank you so much for your help Dr. Ophus @cophus, I will look into the shared codes and files!!
Eric Prestat
@ericpre
Is it expected that the RMS values for mustem and prismatic seems to be an order of magnitude different?
rouviere2
@rouviere2
Hello, by testing prismatic, we found surprising potentials for the different slides using the standard Si001.xyz files. tileX=1, tileZ=6, sliceThickness=1.3575 (a/4).
image.png
image.png
rouviere2
@rouviere2
1) in Si001.xyz some atoms are at z=0, but the first potential slice represent the potential at z=a/4 (a=5.43) 2) I would also expect potential slices to be periodic with a period equal to 4 (not Thermal Effects) 3) some slices have no potentials (atoms are certainly distributed in the adjacent slides) . I put images of the different slices. We tried to look at the code but we have some difficulties understand everything (!) (we are not expert programmers !)
Thomas Aarholt
@thomasaarholt
@rouviere2 Prismatic's "beam" hits the atoms at z=0 last, according to this diagram:
I raised it in this issue: #33
rouviere2
@rouviere2
Thanks Thomas, your links allowed me to understand my first point ! However for the second and third points, I have the feeling that Z_coordinates are not rounded in a perfect way. In the potential table, I sent above, I now understand slice 23 (z=0) and slice 23 (z=a/4), however slice 21 has no atoms...
Luis RD
@lerandc

From here

`

    auto max_z = std::max_element(z.begin(), z.end());
Array1D<PRISMATIC_FLOAT_PRECISION> zPlane(z);
std::transform(zPlane.begin(), zPlane.end(), zPlane.begin(), [&max_z, &pars](PRISMATIC_FLOAT_PRECISION &t_z) {
    return round((-t_z + *max_z) / pars.meta.sliceThickness + 0.5) - 1; // If the +0.5 was to make the first slice z=1 not 0, can drop the +0.5 and -1
});

`

@rouviere2 the inconsistencies you are seeing are most likely a cause of floating point error, which is probably made worse by the back-and-forth normalization (see here, here, and here. Since we first add 0.5 to the index, then round, then subtract an index, if there is a slight floating point error (unavoidable, really), then it could round to the wrong slice. Potentially could be fixed by removing the +0.5, -1, but these should be functionally equivalent and there would probably be other rounding type errors the other way, too

Luis RD
@lerandc
however, I would also like to add that this is an inherent drawback in the 2D projected potential method, since each atom must be flattened and discretely assigned a single slice. in the future, prismatic will have 3D projected potential functionality, which could avoid this entirely since the potential integration is done entirely over 3D space and then converted to equivalent 2D slices. the functionality is currently up in one of my development pipelines (for you or anyone curious to try it out) but won't be out officially for a little while still
Colin Ophus
@cophus
@rouviere2 @thomasaarholt Yes I think there is never going to be a perfect scheme in 2D where you never run into slicing inconsistencies. As @lerandc mentioned, we're going to switch to full 3D potentials in the next release. We're also going to enable input of the potential slices directly so that people can compute or modify them as they wish. Also I should fix the input Si test file - it's probably more reliable and predictable to slice up the cell like this example:
slices at [ 0 - 1/4]c [1/4 - 1/2]c [1/2 - 3/4]c [3/4 - 1]c
and atoms at positions [ 1/8 3/8 5/8 7/8 ]*c along the beam direction
Tara Prasad Mishra
@Quantumstud
It seems there are a lot of updates recently in the Prism-em package. I think it would be important to update the website?
Luis RD
@lerandc
@Quantumstud yes indeed! once all these new changes make their way through some testing and to the main repository, they'll be released together as an update and the website will be updated accordingly (as well as fixing all the things that currently need updating already)
Carter Francis
@CSSFrancis
Hello all, I was just running some simulations where I was looking at a system as a function of the Debye Waller factor. What I found was that it seems like any factor under 1.0 doesn't seem to change the simulation and at 1.0 suddenly the thermal effects are included. After looking at the source code
if (pars.meta.includeThermalEffects)
    { // apply random perturbations
    X = round((x[atom_num] + randn(de) * sigma[atom_num]) / pars.pixelSize[1]);
    Y = round((y[atom_num] + randn(de) * sigma[atom_num]) / pars.pixelSize[0]);
    }
Carter Francis
@CSSFrancis
This seems to suggest that if sigma is less than 1 it is just rounded back to the original position? Maybe I am misunderstanding this and there is another parameter I need to change. The code is from prismatic/src/PRISM01_calcPotential.cpp lines 171-175
Carter Francis
@CSSFrancis
Is it possible that pars.pixelSize is stuck at 1 in the new release? I know there are some changes with the addition of the realSpacePixelSize variable. I can run some more tests a little bit later, but just wondering if anyone with more familiarity could comment.
Luis RD
@lerandc

@CSSFrancis the round is applied the quantity (x[atom_num] + randn(de) * sigma[atom_num]) / pars.pixelSize[1], this rounds the atomic position + displacement to the nearest pixel for the 2D potentials so it can be placed

it should be having an effect below 1, though-- what commit version of the source are you using? the prism-em/master branch was updated with a quick string parsing fix earlier this year. if you don't have that fix, the parser might be dropping the last character in each line, so if you have DW factors 0.1, 0.2, etc., they would be read as 0

the pixelSize shouldn't be stuck at 1
the fix for the above w/o recompiling would be just to add a trailing 0 to each of your DW factors
Carter Francis
@CSSFrancis
@lerandc I was using version 1.2 so that's probably the issue. Thanks for the tip! I'll look into it a bit more but hopefully everything that sorts everything out
deRemarkable
@De_REMARKABLE_twitter
Hello all, I'm new here in terms of Prismatic. Would anyone be kindly enough to tell me if Prismatic could do simple plane wave TEM simulations (rather than STEM)?
ahinroy
@ahinroy
Hello all, I have been trying to read 4D-STEM simulation data generated by Prismatic using py4DSTEM. But, the output HDF5 file from Prismatic is not being recognized by py4DSTEM. As I understand, the EMD attributes are necessary in the Prismatic output HDF5 file to be compatible to py4DSTEM input. Is there a way to write the proper attributes to the output HDF5 through input simulation parameters in Prismatic?
Thomas Aarholt
@thomasaarholt
@ahinroy, I believe @ericpre added prismatic support in the latest master of hyperspy. I don't know if py4DSTEM directly relies on hyperspy for that import, but you can try.
Luis RD
@lerandc
@ahinroy I just checked against the most recently updated version of py4DSTEM and am hitting the same import issues-- looks like it's related on my end to the top group being named "4DSTEM_simulation" instead of "4DSTEM_experiment". there used to be a check in the repository for this very issue but it may have gotten lost in some recent updates (py4DSTEM went through a decent overhaul in its file IO module in the past months)
does your error log report something at this at the end of the stack trace when you try to the open the file? KeyError: "Unable to open object (object '4DSTEM_experiment' doesn't exist)
@De_REMARKABLE_twitter with version 1.2 of Prismatic, plane wave simulations are currently not possible; however, the functionality is mostly through the development pipeline and will certainly be a part of the next release!
ahinroy
@ahinroy
@lerandc I changed the topgroup through h5_py to "4DSTEM_experiment", even then the file is not readable by py4DSTEM. The only difference between the Prismatic output (after renaming the "4DSTEM_simulation" to "4DSTEM_experiment") and the recommended py4DSTEM input are the EMD attributes.
Luis RD
@lerandc

@ahinroy by changed the top group, do you mean you created a copy of the original top group with "4DSTEM_experiment" key? I couldn't find a way to change the name of an existing group with h5py; relinking stuff like this is generally prety hairy with HDF5 in my experience

in any case, though, the EMD attributes are attached to the top group as emd_group_type = 2, major version = 0, minor version = 5. with h5py, I see them with the command f['4DSTEM_simulation'].attrs.keys()--can you verify that this is the same case for you? py4DSTEM is currently on v0.9, so there are a host of little changes to be made to the file format anyway, and after poking around and testing a couple of other things, there doesn't seem to be a legacy reader for v0.5 in py4DSTEM at the moment, so even if things were aligned we'll run into issues

this can, in the time between now and the next release of prismatic, be much more quickly adressed on the py4DSTEM side, so I'll see what I can manage there in terms of a quick patch
ahinroy
@ahinroy
@lerandc right, I created a copy and tried to use that as py4dstem input, and that didn't work. With hdfview, I could not see the attributes in the prismatic output. I also agree that this will be better resolved on the py4dstem side. And thanks a ton for arranging the quick patch :)
Eric Prestat
@ericpre
@lerandc, would it more simple to keep 4DSTEM_simulation and avoid introducing breaking changes?
https://emdatasets.com/format says "This group may have any name: files saved by py4DSTEM name this group “4DSTEM_experiment” while files produced by Prismatic name it “4DSTEM_simulation.”"
assuming that this page is a reference for what is the emd file format, 4DSTEM_simulation would be fine as top group name
Luis RD
@lerandc
@ahinroy interesting, is this happening with the current GUI version or have you compiled your own?
@ericpre yes, it would be simpler to keep it-- and we would want to keep it so that the semantic separation is clear when analyzing data anyway. the top group situation has been sorted out already by Ben Savitzky, we now just need to check if the v0.6 legacy reader would work for prismatic (which is at v0.5 in terms of py4DSTEM versioning), and if not, write in a new legacy reader simlar to the one already implemented
ahinroy
@ahinroy
@lerandc I am not using the GUI. I have installed the Prismatic using conda and running the simulations in a parallel CPU architecture.