IVAS Feedback/2.3

From Northwestern University Center for Atom-Probe Tomography
Revision as of 00:06, 25 March 2006 by Karnesky (talk | contribs) (→‎Envelope)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Feedback presented at the Dec 9, 2005 software meeting is stored in IVAS Feedback/2.3/Meeting. Please add new feedback below.

Questions

  • Is there a way to stop the 3D gaussian calculation when we change the delocalization to something we decide we don't want?
    • The 3D filtering issue is problematic with regard to CPU utilization. We hope to allow a "cancel" option on all time intensive operations by 3.0. We are also looking to implement an 3D FFT smoothing implementation as we have observed a 2 order of magnitude speed increase. I'm pursuing another issue that might be affecting isosurface smoothness.
  • When I add a Mo2C range around 24, the envelope method outputs a lot of overflow errors. When I run it for just the Mo range, it outputs a few overflows but still returns clusters. However, when I run it with both ranges, it outputs many overflow errors and no clusters. Is there a reason for this? -Mike
  • What is the physical meaning of a negative volume & when can we expect to see them? If it is "not real" (e.g. is only some artifact of attempting the calculation for non-closed segments of the isosurface), is there a way to "fix it" (perhaps by assuming some geometry that will close the precipitates or even by just NULLing the values)?
    • The volume calculation is experimental at this point and only works for closed surfaces. We're not actually sure it will remain in the software. If you were to use the option to fill in missing values to get precipitates without any holes you should only see positive volumes. We're looking at other ways of calculating the volume but were hoping for some internal feeback on this. If we can find an easy way to determine whether or not a surface is closed, we will just display something like 'N/A' in that column.

Feature Requests

  • A way to quickly mae the x and y clipping dimensions the same (e.g. a square cross-section) and/or the ability to clip an isosurface/BCR to have a square cross-section with no void pixels. (Some roughness calculations rely on Fourier transforms & so need this geometry.)
    • Your BCR export issues (void pixels, uniform x/y) are valid issues and should be addressed, but I can't guarantee a time frame.

Bug Reports

General

Apex vs IVAS

Thanks to Dieter and Tom for helping me think through this again

  • Grid atoms
    • IVAS with Gaussian of width=voxel
    • Apex with sawtooth or square of width=voxel
  • Delocalization
    • Both with Gaussians of width=delocaPostioning atoms in voxels:
  • Confidence sigma
    • IVAS doesn't do this
    • Apex subtracts from all of concentration space
  • Isosurface generation
    • Should be the same
  • Isosurface thresholding
    • IVAS allows you to exclude parts of the surface by atoms or by # of polygons
    • Apex doesn't do this

Volume separation

One idea re. proxigrams clustered by interface volume would be to have the ability to run a separate proxigram across every ppt & to group them, after-the-fact, by the total number of atoms contained within the surface.

Scripting

Is there any way to script the isosurface analysis functions to perform repetitive tasks (such as the above, or the ability to export ALL proxigrams to CSV, etc.)?

  • I'll have to look into this for you. Our APIs are changing very rapidly so I'm hestitant dig too deeply into this or get you started as any work done will mostlikely be end-of-lifed before it's done... I'm glad you've asked this question, it remphasizes our need to constantly rexamine out APIs for access and usability.

Envelope

We had previously complained that envelope.exe doesn't work on datasets where there are too many clusters or too many precipitates (it either complains that there are too many clusters, or doesn't finish generating output (particularly: the three text files will be empty)). Because of this, we can't run precip.py (and so I can't get out the transform3Ds for my external analysis) unless we trim the datasets down.

We have a few datasets with >500 precipitates which we'd like to extract in a single pass. We'd like to publish these sets soon. Can you please fix the envelope routine to allow us to do this? (And/or give an approximate timeline for implementation.)

An additional feature request for this is to thread this to take advantage of our multiprocessor machines, but this is not as urgent as having it WORK for sets with more precipitates.