Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 15 18:21
    cophus commented #2
  • Sep 15 18:18
    cophus commented #4
  • Sep 04 21:20
    thomasaarholt opened #4
  • Aug 29 08:21
    thomasaarholt closed #1
  • Aug 29 08:21
    thomasaarholt commented #1
  • Aug 29 08:20
    thomasaarholt commented #2
  • Aug 29 08:06
    thomasaarholt closed #3
  • Aug 29 08:06
    thomasaarholt commented #3
  • Aug 29 08:06
    thomasaarholt commented #3
  • Aug 28 17:18
    cophus commented #2
  • Aug 28 17:13
    cophus commented #1
  • Aug 28 17:05
    cophus commented #3
  • Aug 27 07:32
    thomasaarholt opened #3
Colin Ophus
@cophus
image.png
@wangshuai1212_gitlab So finally at 8x8 tiling of your cell (to about 64 x 64 Angstroms) you can see the Probe's boundary conditions are maintained - no probe wraparound error visible, even with "log scaling" checked

@wangshuai1212_gitlab Looking closely, you could perhaps get away with 4x4 tiling, but I'd do 6x6 or 8x8 to be safe - also note you MUST use PRISM interpolation factors f = 1, or multislice. Overall summary: both your Prismatic and Dr. Probe simulations are completely wrong due to using a unit cell that is too small.

Final note: Prismatic can't really handle using no thermal vibrations due to the way I implemented the potential integration - and to get HAADF results that are even close to realistic, you need to include this Debye-Waller factor! I used u_RMS = 0.1 Angstroms which is a pretty reasonable value for most materials. Use thermal vibration for Dr. Probe too!

Wang
@wangshuai1212
thank you Colin. I will check again with the new input and give you feedback!
Mohsen
@M0hsend
ibf_20mrad.png
dp_sum2.png
Hi, I am simulating some 4D-STEM outputs from bilayer graphene and graphene with a defect. The former's outpute is as expected: datacube is (85,84,42,42) with ibf and sum pattern as above.
In the latter case, I get a weird output size of (146, 163, 72, 82)- with the pattern as non-square. with the ibf and sum pattern as below (note the oval BF disc):
sw_20mrad_100Adef_ibf.png
sw_20mrad_100Adef_sum_dp.png
Just wondering why this is happening. I am using Prismatic-GPU-v1.2.1 on a Windows 10 machine
Thomas Aarholt
@thomasaarholt
@M0hsend are you sure you are using the same input file for both simulations? It doesn't seem like it.
Mohsen
@M0hsend
@thomasaarholt The coordination files are of course different. All the other parameters are the same though.
Thomas Aarholt
@thomasaarholt
Can you provide the input files?
bilayer case above
Thomas Aarholt
@thomasaarholt
I also notice that in the first dataset, the colorbar on the navigation window is about 1, and in the second it's much much higher
with defect one above
@thomasaarholt yeah that is because I have multiplied the intensity by a factor. Ignore that.
Thomas Aarholt
@thomasaarholt
Oh, yeah
Unlike software like MULTEM, prismatic let's you control the pixel size rather than the total number of pixels - for probe step and the potential spacing
That explains why you get the different number of pixel size - since that the number is a function of the pixel size and the size of your input model
The reason you get an oval disc is a bit stranger - could you double check that the cell dimensions you've entered in the input file match the cell dimensions of the xyz file?
Might need @cophus if that's not it.
lerandc
@lerandc

@M0hsend My guess would that it would be related to some rounding that occurs when the array sizes are calculated in params.h (https://github.com/prism-em/prismatic/blob/master/include/params.h). The important part is between lines 195-210.
Essentially, the diffraction image dimension is calculated as:
im_size = f * round(cell_dim / (real_pixel_size * f))

Since the image is rounded to an integer number of pixels, the physical pixel size is recalculated as:
pixel_size = cell_dim/im_size

running the calcualtion for your input files, then, it seems like for the 1st file the final pixel sizes are neglibly close (0.1996, 0.2017); the second file is a bit more different (0.2016, 0.1978)

Mohsen
@M0hsend
Many thanks @lerandc Will try with a modified cell dim then.
SE Zeltmann
@sezelt
@douglowe @lerandc today i was working on something totally unrelated, and an incompatibility between anaconda and this other package forced me to switch to using python installed by homebrew, and while installing something I got a warning about a pyprismatic dependency... lo and behold, if i use the Homebrew-installed python, pyprismatic works! it imports correctly no matter where you launch it from, so the path issues are ok there
Douglas Lowe
@douglowe
@sezelt thanks for this helpful pointer - I’ll check with homebrew on my mac, see if it works for me too. Not sure what that means for packaging with conda if it does work, but at least it will be more information on the problem.
Tom Schoonjans
@tschoonj
Hi all, I manage the conda installations at Diamond Light Source (where @M0hsend works...) and I have submitted pyprismatic to conda-forge (https://github.com/conda-forge/staged-recipes/pull/10396). I am using the version on PyPI which appears to be a bit out of data: 1.1.16 (PyPI) vs 1.2.1 (GitHub). Are there any plans to update PyPI?
Thomas Aarholt
@thomasaarholt
+1 to that
Douglas Lowe
@douglowe
@tschoonj - we've (literally, this morning) just got a package for prismatic (gui & cli, linux & OSX) plus pyprismatic (linux only, so far) accepted for distribution on conda-forge: conda-forge/staged-recipes#9834 . If you'd like to help out with the last steps of getting this into conda-forge (and then updating & extending what we have now) then I would be very happy to add you to the list of maintainers?
Tom Schoonjans
@tschoonj
Cool, I had no idea about that PR. I will close mine. Feel free to add me as a maintainer
Douglas Lowe
@douglowe
@tschoonj great - I've added you as a maintainer now (hopefully you've had an email for this). The repository is here: https://github.com/conda-forge/prismatic_split-feedstock
Tom Schoonjans
@tschoonj
I have: thanks!
Douglas Lowe
@douglowe
Prismatic for OSX and linux is now available via conda forge. You can install it using: conda install prismatic -c conda-forge
Currently it is only the CPU driven model. The CLI and GUI interfaces are available for both OSX and linux, while pyprismatic is available too for linux.
To install the individual packages for these use:
conda install prismatic_gui -c conda-forge or conda install prismatic_cli -c conda-forge or conda install pyprismatic -c conda-forge
Douglas Lowe
@douglowe
@cophus - would it be possible to add the information about the conda-forge packages to the prismatic website?
SE Zeltmann
@sezelt
it also didn't seem to do anything re pyprismatic
and trying to install pyprismatic on its own gives package not found error

conda install pyprismatic -c conda-forge
Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Collecting package metadata (repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.

PackagesNotFoundError: The following packages are not available from current channels:

  • pyprismatic

Current channels:

gudutu19
@gudutu19
Hi all, I am not very sure about the indication of wraparound. Are those dot-like features caused by wraparound?
image.png
This image is from Colin's reply to Wang's question
The reason why I ask this is that I am not quite sure whether my tiling cells are enough to avoid wraparound.
Here is the screenshot of my settings.
image.png
Douglas Lowe
@douglowe
@sezelt thanks for trying the conda packages out - unfortunately we've not got any further with getting pyprismatic packaged for OSX yet. I still need to check your tip about the homebrew python install, and after that then work out if we're able to make use of this for building & packaging pyprismatic for conda-forge.