Comments from Peter Felfer

[Daniel Haley]

Hi All,

I've spoken with Peter Felfer, who is working on his own atom probe
system, and he has provided some comments on our standard.

From his side, he is wondering whether some data should be in float-64,
rather than float-32, in case of loss of precision issues. Some
additional concerns were raised about the delay lines (or other
detector) themselves. Meta-data such as pulse acquisition mode (e.g.
discriminator or time-resolved conversion) may not be correctly captured
in our current revision of the standard.

Importantly, Peter has agreed to implement reader/writer routines to
ensure his software is compatible with any standard we agree to, so
there seems to be good support for our efforts, and to improve
inter-operability.

I've attached Peter's notes here - please let me know your thoughts.

--Dan

[Markus Kühbach]

Hi Daniel,

Thank you for getting in touch with Peter and sharing tis comments.

With respect to data precision I tend to follow Peter's argument to go about

usingf64 and (u)int64. However, it is also true that for most (raw) quantities stored

within APT, the significant precision is below what is resolvable with 32bit formats.

So using the lower precision is a quick and practical approach to safe disk space in many

applications. 64 vs 32 in terms of processing speed is a more complex questions, rather

second order and strongly implementation-dependent.

For tessellations build from f32 x,y,z data I use f64 and I recommend doing so

because 64bit precision at least reduces the number of cases with a risk

for potential numerical degeneracies.

Wrt to this other comments I do accept Peters request to specify in more detail the detector.

How is it going about with the APT&M related virtual (pre)meeting on matters of opening

up APT data, is this still a topic and will there be session as a replacement this summer?

Bests,

Markus

----------------------------------------------------------------
Dr.-Ing. Markus Kühbach

Max-Planck-Institut für Eisenforschung GmbH

Department "Microstructure Physics and Alloy Design"
Research group "Theory and Simulation"
Room 649
+49 211 6792 385
m.kue...@mpie.de

--
You received this message because you are subscribed to the Google Groups "AtomProbe TC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to atomprobe-tc...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/atomprobe-tc/1e21de90-7cb2-ae85-d76c-acb00ab93f0d%40materials.ox.ac.uk.

---

-------------------------------------------------
Max-Planck-Institut für Eisenforschung GmbH
Max-Planck-Straße 1
D-40237 Düsseldorf
 
Handelsregister B 2533 
Amtsgericht Düsseldorf
 
Geschäftsführung
Prof. Dr. Gerhard Dehm
Prof. Dr. Jörg Neugebauer
Prof. Dr. Dierk Raabe
Dr. Kai de Weldige
 
Ust.-Id.-Nr.: DE 11 93 58 514 
Steuernummer: 105 5891 1000


Please consider that invitations and e-mails of our institute are 
only valid if they end with …@mpie.de. 
If you are not sure of the validity please contact r...@mpie.de

Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails
aus unserem Haus nur mit der Endung …@mpie.de gültig sind. 
In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de
-------------------------------------------------

[London, Andy]

Hi all,

I also agree with Peter's comments that 64 precision seems like the way forward, I don't know whether there is an easy option to switch at a later date. I'm also not sure how the compression differs, say if single floats were converted to 64-bit (e.g. converting an existing pos file), would they be more easily compressed than true 64-bit data?

Peter's comments about the detector specification also seem reasonable, expect in the case of the LEAP equipment information about the specifics of the detector may not be known.

Andy

---

From: atompr...@googlegroups.com <atompr...@googlegroups.com> on behalf of Markus Kühbach <m.kue...@mpie.de>
Sent: 03 June 2020 11:13
To: atompr...@googlegroups.com <atompr...@googlegroups.com>
Subject: Re: Comments from Peter Felfer

 

To view this discussion on the web, visit https://groups.google.com/d/msgid/atomprobe-tc/1404746921-3096%40xmail1.mpie.de.

[Markus Kühbach]

Hi all,

@Andy:

as said f64 is okay. In my personal opinion, we ask even better how many significant numbers are we really expected to measure

and judge thereby which precision to choose for storing data. Are atoms really more precise than 1.0e-5 or is the rest just noise,

noise we have to carry and pump through? F64 is for sure a conservative choice to be safe.

You can go from F32 to F64 for sure there are at least two points to have in mind thought:

i) this does not per se improve precision it just mitigates the chance of running into numerical issues

because somehow the choices are made in the least significant bits.

I admit this is already a quite special application like you have x,y,z f32 data and want to compute a tessellation.

ii) Casting up from F32 to F64 naively however will not necessarily avoid noise in the least significant bits and therefore

create data blow-up; a blow-up which is not necessarily well loss-less compressible.

Going the other way round may be counter-intuitive when thinking about reproducibility, say you have data where

the 1.0e-12 difference matters, who takes care about this when people use Matlab or Python the usual way

where the beauty is that data get their types implicitly... an interesting question for sure.

@Andy:

On the virtual meeting session, I think hash and data format topics should get a slot,

I am happy to contribute on FAIR and ideally Hash+FAIR for APT post-processing.

Bests,

Markus

----------------------------------------------------------------
Dr.-Ing. Markus Kühbach

Max-Planck-Institut für Eisenforschung GmbH

Department "Microstructure Physics and Alloy Design"
Research group "Theory and Simulation"
Room 649
+49 211 6792 385
m.kue...@mpie.de

To view this discussion on the web, visit https://groups.google.com/d/msgid/atomprobe-tc/LNXP265MB1050256D127A75CAECD5A67585880%40LNXP265MB1050.GBRP265.PROD.OUTLOOK.COM.

[Daniel Haley]

Hi All,

One option would be to relax the standard as it currently reads from
specifying 32 or 64, and encouraging the use of a type that matches the
necessary precision for subsequent use, recommending 32 as the default.

This pushes these concerns onto developers. The question is whether this
raises compatibility issues. Off the top of my head, I don't think it
does beyond Markus' concerns below, but I'm not totally sure.

Another alternative is we could specify that software *should* mask bits
to zero where they are not needed (as determined by the generating
software), in order to improve compression. However, a few real-world
trials of this should be done if we want to go down that road, so we are
not over-complicating things for insufficient benefit.


--Dan

> *From: * "London, Andy" <andy....@ukaea.uk>
> *To: * "atompr...@googlegroups.com" <atompr...@googlegroups.com>
> *Sent: * 6/3/2020 4:58 PM
> *Subject: * Re: Comments from Peter Felfer

>
> Hi all,
> I also agree with Peter's comments that 64 precision seems like the
> way forward, I don't know whether there is an easy option to switch
> at a later date. I'm also not sure how the compression differs, say
> if single floats were converted to 64-bit (e.g. converting an
> existing pos file), would they be more easily compressed than true
> 64-bit data?
>
> Peter's comments about the detector specification also seem
> reasonable, expect in the case of the LEAP equipment information
> about the specifics of the detector may not be known.
> Andy

> ------------------------------------------------------------------------
> *From:* atompr...@googlegroups.com

> <atompr...@googlegroups.com> on behalf of Markus Kühbach
> <m.kue...@mpie.de>

> *Sent:* 03 June 2020 11:13
> *To:* atompr...@googlegroups.com <atompr...@googlegroups.com>
> *Subject:* Re: Comments from Peter Felfer

> *From: *Daniel Haley <daniel...@materials.ox.ac.uk>
> *To: *<atompr...@googlegroups.com>
> *Cc: *"Felfer, Peter" <peter....@fau.de>
> *Sent: *6/3/2020 10:11 AM
> *Subject: *Comments from Peter Felfer

> ------------------------------------------------------------------------

> <mailto:atomprobe-tc...@googlegroups.com>.

> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/atomprobe-tc/1404746921-3096%40xmail1.mpie.de
> <https://groups.google.com/d/msgid/atomprobe-tc/1404746921-3096%40xmail1.mpie.de?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "AtomProbe TC" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to atomprobe-tc...@googlegroups.com

> <mailto:atomprobe-tc...@googlegroups.com>.

> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/atomprobe-tc/LNXP265MB1050256D127A75CAECD5A67585880%40LNXP265MB1050.GBRP265.PROD.OUTLOOK.COM
> <https://groups.google.com/d/msgid/atomprobe-tc/LNXP265MB1050256D127A75CAECD5A67585880%40LNXP265MB1050.GBRP265.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.
>
>
>
> ------------------------------------------------------------------------

> <mailto:atomprobe-tc...@googlegroups.com>.

> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/atomprobe-tc/1426273734-4660%40xmail1.mpie.de
> <https://groups.google.com/d/msgid/atomprobe-tc/1426273734-4660%40xmail1.mpie.de?utm_medium=email&utm_source=footer>.

[Anna Ceguerra]

Hi all,

I think some fields only need 32-bit precision, whereas other fields need 64-bit, but it should be specified. I don't think a standard should be vague. If it turns out a 32-bit field needs 64-bit later, we can publish an amendment to the standard.

Regards,
Anna.

> https://protect-au.mimecast.com/s/SxYlC1WLPxcwNzq3ULkDsQ?domain=groups.google.com.

> https://protect-au.mimecast.com/s/omehC2xMQziozl81S1IyjN?domain=groups.google.com
> <https://protect-au.mimecast.com/s/GUAWC3QNPBiYzA2qU2zheK?domain=groups.google.com>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "AtomProbe TC" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to atomprobe-tc...@googlegroups.com
> <mailto:atomprobe-tc...@googlegroups.com>.
> To view this discussion on the web, visit

> https://protect-au.mimecast.com/s/W8vUC4QOPEiAK0lgHWX6X0?domain=groups.google.com
> <https://protect-au.mimecast.com/s/nTP-C5QPXJiYLj6EUxyQ7q?domain=groups.google.com>.

> https://protect-au.mimecast.com/s/6getC6XQ4LflYOyzILc_4E?domain=groups.google.com
> <https://protect-au.mimecast.com/s/qwITC71R2NTj1pZlC0uB1s?domain=groups.google.com>.

--
You received this message because you are subscribed to the Google Groups "AtomProbe TC" group.

To unsubscribe from this group and stop receiving emails from it, send an email to atomprobe-tc...@googlegroups.com.

To view this discussion on the web, visit https://protect-au.mimecast.com/s/JEePC81V0PT8pvY1FRNa-D?domain=groups.google.com.