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
Tara Prasad Mishra
@Quantumstud
@lerandc Thanks for the reply!! Yes, for the multicore cluster, prismatic doesn't parallelize with across the different physical cores. Hence the maximum cores that can be used in my cluster are 24. Even if I use 48 cores, only 24 cores are used, and the remaining 24 cores are not utilized. Is there any workaround for that?
@yobc401 Hi! I am also using a supercomputing cluster to run Prismatic. The easiest way is using the Conda package thanks to the prism Conda package that is now available. You can install anaconda locally in your account and then use 'conda install -c conda-forge prismatic' By this, you don't have to have the root or sudo access!
Thomas Aarholt
@thomasaarholt
@yobc401 Even simpler: In the anaconda distribution you are using, create a new environment. This will automatically be created in your local directories, where you have writing access. conda create --name pris -c conda-forge prismatic will do what you want.
zhantaochen
@zhantaochen
Hi there, I was wondering does Prismatic require the unit cell (xyz file) to have alpha, beta, gamma=90 degree? Are we supposed to convert coordinate to orthogonal basis, and could any of you please suggest me some effective ways to do this type of work? I tried searching on Prismatic website and this chatting room but could not find too much related information (except the graphene one but seems no xyz file available to confirm my thoughts). I will appreciate any guidance!
Colin Ophus
@cophus
@zhantaochen Yes Prismatic requires alpha = beta = gamma = 90 degrees. I always convert cells to orthogonal using rational or pseudo-rational approximates. What cell do you need to transform? If you send it to me, I might be able to provide you with a worked example
zhantaochen
@zhantaochen
@cophus Thank you for the response Dr. Ophus! I do not have a target material for now, but am generally curious how to deal with non-orthogonal unit cells. I think graphene would be a great starting point (I have attached a cif file downloaded from Materials Project). Could you please elaborate a bit more, or just throw me a link, about the (pseudo-)rational approximations? I could not find related information after a quick search. I was also wondering does Prismatic directly tile input unit cells? If so, I will pay additional attention to boundaries to make sure periodicity is not interrupted between tiled UC's. Sorry for so many questions...
@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)