Vote : Standards dissemination

[Daniel Haley]

Hi all,

As required by our charter, I am calling for a vote for the following
action:

To disseminate the current draft standard on APT-HDF, for a "Request for
comments" phase from the community, where we invite the wider community
to review the document.

The proposed standard and the associated software links will be provided
as part of the mailout. Dissemination will be via the ISC, likely the
IFES mailing list.

The publicly visible standard document is here:
https://docs.google.com/document/u/2/d/e/2PACX-1vRxcJ_xF_jiNS77CoeZdQdDXD8l2BebL-DoOBkDrAsGTrkArdjLHEMCXAifBieeS8pTO9jJ9xnstKxs/pub

Option 1: Disseminate the Draft standard
Option 2: Withhold the Draft standard for further reivsions.

Please indicate in your response:

"Vote : Option X", where X is 1 or 2

If there are small errors that should be corrected, please directly
modify the document, rather than withholding. If you believe further
revisions are needed, we can discuss this separately to your vote.

Please do submit your vote as soon as possible.

Thanks,

Daniel

[Daniel Haley]

Vote : Option 1

[Dieter Isheim]

Vote: Option 2

"Withhold the Draft standard for further revisions"

Comments:
(1) there should be an introduction that explains what this is for (what are the benefits, who should use this?). Very few people in the community might be able to guess a broader purpose (beyond the stated “utilise existing file storage technologies … [for] high performance primitives").
(2) there should be a brief explanation of what HDF5 is, and why it is chosen for the proposed standard (benefits?) - I would not assume this is broadly established in the broader APT community.
(3) how are we dealing with parameters that are not easy to come by, e.g., how do I know the "Virtual imaging distance” for my instrument? Laser spot size, beyond the nominal value given for a specific instrument type by hearsay? Is there an established procedure how to measure that, e.g. FWHM of a laser scan?
(4) there seem still to be missing some basic experimental parameters, e.g. the base vacuum of the instrument or perhaps vacuum evolution during the experiment. Specimen preparation details? Perhaps the intent is to have Specimen Prep included with “SampleDescription”, at 5MB there is plenty of room, compared to the max 100 or 200 characters limit for other specimen descriptors, but this is not explicitly asked for. These may be minor points, but I think the standard should be reasonably complete and detail-balanced before presenting it to the community for comment.
(5) In terms of extensibility of the format, should “Additional fields are strongly discouraged” really be the only thing we have to say? Are there any plans how to deal with potential revisions or extensions, beyond including a HDF5 version number?

Regards - Dieter

> On Jun 20, 2020, at 5:54 PM, Daniel Haley <daniel...@materials.ox.ac.uk> wrote:
>
> Hi all,
>
> As required by our charter, I am calling for a vote for the following
> action:
>
> To disseminate the current draft standard on APT-HDF, for a "Request for
> comments" phase from the community, where we invite the wider community
> to review the document.
>
> The proposed standard and the associated software links will be provided
> as part of the mailout. Dissemination will be via the ISC, likely the
> IFES mailing list.
>
> The publicly visible standard document is here:

> https://urldefense.com/v3/__https://docs.google.com/document/u/2/d/e/2PACX-1vRxcJ_xF_jiNS77CoeZdQdDXD8l2BebL-DoOBkDrAsGTrkArdjLHEMCXAifBieeS8pTO9jJ9xnstKxs/pub__;!!Dq0X2DkFhyF93HkjWTBQKhk!CorIUnFU5EPMI9si6n4NcNolM7SXR2V4rsOiSEq3czYYQWDbdUFY803Wl_42BiT5hlKm$

>
> Option 1: Disseminate the Draft standard
> Option 2: Withhold the Draft standard for further reivsions.
>
> Please indicate in your response:
>
> "Vote : Option X", where X is 1 or 2
>
> If there are small errors that should be corrected, please directly
> modify the document, rather than withholding. If you believe further
> revisions are needed, we can discuss this separately to your vote.
>
> Please do submit your vote as soon as possible.
>
> Thanks,
>
> Daniel
>

> --
> 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://urldefense.com/v3/__https://groups.google.com/d/msgid/atomprobe-tc/7422bf19-8640-be24-a788-3cb2927aff59*40materials.ox.ac.uk__;JQ!!Dq0X2DkFhyF93HkjWTBQKhk!CorIUnFU5EPMI9si6n4NcNolM7SXR2V4rsOiSEq3czYYQWDbdUFY803Wl_42BhsZTfEW$ .

[London, Andy]

Vote: Option 2

I would tend to agree with Dieter, we are lacking in general instructions in the document (beyond basic descriptions).

I don't think much should be said about sample preparation (for example) apart from that which was necessary to identify the specimen in an associated body of work. We're not looking to document everything in the HDF5 file, rather we want to capture the experimentally determined atom probe data and related meta-data. I guess you could cast the meta-data net quite wide, but I don't think we advocating having a total description of the experiment in there either. Perhaps a guiding principal might be, "Whatever is useful to know for the atom probe analysis", so approximate or bulk composition, expected phases, material state (quenched, annealed, irradiated), perhaps how the specimen was prepared - as this can influence what species are found.

I also think we need a little more development of the code, I know when I was trying to get Matlab write something the C++ validator was happy with, we found lots of bugs/issues.

Andy

---

From: atompr...@googlegroups.com <atompr...@googlegroups.com> on behalf of Dieter Isheim <ish...@northwestern.edu>
Sent: 21 June 2020 04:16
To: atompr...@googlegroups.com <atompr...@googlegroups.com>
Subject: Re: Vote : Standards dissemination

 

To view this discussion on the web, visit https://groups.google.com/d/msgid/atomprobe-tc/6B91E39A-1111-4D5B-AE80-6CD11E335A8B%40northwestern.edu.

[Markus Kühbach]

Dear colleagues,

I vote for Option 2

I follow in principle the arguments of Dieter and Andy, see in replies to

their emails maybe a few more ideas to solve here.

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

From: "London, Andy" <andy....@ukaea.uk>
To: "atompr...@googlegroups.com" <atompr...@googlegroups.com>
Sent: 6/22/2020 11:00 AM
Subject: Re: Vote : Standards dissemination

Vote: Option 2

I would tend to agree with Dieter, we are lacking in general instructions in the document (beyond basic descriptions).

>> I try to take the experimentalist perspective and assume I have no idea about HDF5. When I start reading the draft, let me see where
I get to: I asked myself the following questions, I feel they need to be answered, I try below at least a sketch of an answer:

What is the key problem the standard solves?

-> This is unclear to me, possible answer:

-> The content of most established APT file formats which keep the large datasets is not human-readable.

-> Here standard solves this and makes content from APT measurement human-readable.

-> Here standard is also a solution to store the metadata, i.e. the data (descriptions) about the content of the file.

-> Examples of metadata are units, descriptions of the purpose of variables, or the dimensions of the dataset.

I know there is RHIT and HITS. I heard these file formats are not open source. Does here standard change this?

-> Yes and no. Yes because here standard specifies a file format which is human-readable and accessible with open tools.

->No because content from RHIT and HITS file contains unprocessed raw data for which the protocols to transform

these into human-readable CAMECA-agnostic format is not possible because the IVAS source code is not open.

Can I import a APT-HDF5 file back into APSuite6/IVAS4, or older IVAS versions?

-> No, not at this point.

So why should I care then, why is an APT-HDF5 file relevant for me? Will APSuite6/IVAS4 only write these in the

future?

-> This is a though comment but I think a valid criticism to us...

-> There is a number of complementary software tool from the APT community which can already read APT-HDF5 formats.

Support is expected to grow and part of a vision for a more open and accessible approach to APT processing.

-> Open formats which keep the metadata are useful because they enable me as an experimentalist to organize my results

better. Also such format enables me to go back to an analysis and will assist me in figuring out what the heck I did back then.

Proprietary formats or doing this with IVAS exclusively works only if the version of IVAS has not changed.

(The last statement is a maybe too inaccurate claim, please check)

Why HDF5, what the heck is this at all?

The Hierarchical Data Format version 5, or HDF5 for short, is an open source library and file format specification

which facilitates open data exchange, fast file operations for both small but also very large datasets.

Is there an example? What should I do with the specification?

>> There is no hint here in the standard, so maybe this is too complicated...

>> It seems that just some people tried to agree on something, this is likely good, reading the author list, but why is it important for me?

-> We need to have an example POS/EPOS file and a transcoder tool to go from POS/EPOS to APT-HDF5 and back.

-> We need to have a Python and a Matlab script with which people can access the content.

-> We also need an explanation how to view HDF5 file. HDF5View and h5dump is not the common knowledge of APTers.

Who are the authors of the standard?

>> Unclear

Where can I post my questions?

>> Unclear, so again why should I care

I don't think much should be said about sample preparation (for example) apart from that which was necessary to identify the specimen in an associated body of work.

>> I tend to agree because I fear that many will misunderstand the term "sample prep" and maybe then write all the details of their polishing and milling steps.

As of now this is not even part of the file spec and hence it is unclear what to say here, likely Ands comment here gives and implicit answer what is expected when

populating this field.

We're not looking to document everything in the HDF5 file, rather we want to capture the experimentally determined atom probe data and related meta-data.

>> For power readers people my fear is that they think they need to populate all fields, maybe we need to be stronger on this one,

what is essential, mark it green or black, what is optional mark it yellow or grayed out and what is maybe not even necessary, kick it out

I guess you could cast the meta-data net quite wide, but I don't think we advocating having a total description of the experiment in there either. Perhaps a guiding principal might be, "Whatever is useful to know for the atom probe analysis", so approximate or bulk composition, expected phases, material state (quenched, annealed, irradiated), perhaps how the specimen was prepared - as this can influence what species are found.

>> THIS IS EXACTLY WHY WE NEED TO WORK ALONG SUCH THOUGHTS. What is essential to an analysis different people will have different options about it.

We just need to make sure that we make the documenting of metadata as convenient, i.e. as automatic as possible and store more metadata to an experiment.

>> I would like to strongly advocate against trying to weave a too complicated metadata graph with this file format spec.

>> Yes, metadata are embedded in a graph, yes, the entire workflow of an APT research study can be seen as a very large graph with directed and undirected sections.

From which multiple sub-graphs can be taken and inspected. But but but : we are not at all there yet and this goes immediately quite far away

from a sole file spec only and above the heads and interest of many practitioners.

I agree we should think along such lines but this is research, research, which, as I frequently get told, is not what the APT TC is supposed to be doing.

My idea of defining exactly named fields like we have right now in the standard was to take out the smallest possible sub-graph and metadata which are

specific for only taking a measurement with an APT tomograph and get a results file.

I also think we need a little more development of the code, I know when I was trying to get Matlab write something the C++ validator was happy with, we found lots of bugs/issues.

>> I was not aware of these challenges but typically this is also somewhat expected during software development.

>> In the long run, it might be better to have the validator ideally in Python and Matlab, it is easier accessible than is C++

and performance for the validator is not much of an issue.

Andy

---

From: atompr...@googlegroups.com <atompr...@googlegroups.com> on behalf of Dieter Isheim <ish...@northwestern.edu>
Sent: 21 June 2020 04:16
To: atompr...@googlegroups.com <atompr...@googlegroups.com>
Subject: Re: Vote : Standards dissemination

 

Vote: Option 2

"Withhold the Draft standard for further revisions"

>> Agreed

Comments:
(1) there should be an introduction that explains what this is for (what are the benefits, who should use this?). Very few people in the community might be able to guess a broader purpose (beyond the stated “utilise existing file storage technologies … [for] high performance primitives").

>> Yes

(2) there should be a brief explanation of what HDF5 is, and why it is chosen for the proposed standard (benefits?) - I would not assume this is broadly established in the broader APT community.

>> Why HDF5?

-Open format

-Human readable

-Fast performance for both small and PB large files
-Metadata capabilities

-In-place compression capabilities

-Defined endianness

-Defined data layout and dimensions

-Possibility to store structured data in a hierarchy to help organizing thoughts and data

(3) how are we dealing with parameters that are not easy to come by, e.g., how do I know the "Virtual imaging distance” for my instrument? Laser spot size, beyond the nominal value given for a specific instrument type by hearsay?  Is there an established procedure how to measure that, e.g. FWHM of a laser scan?

>> I have no clue, I am not an expert on this

(4) there seem still to be missing some basic experimental parameters, e.g. the base vacuum of the instrument or perhaps vacuum evolution during the experiment. Specimen preparation details? Perhaps the intent is to have Specimen Prep included with “SampleDescription”, at 5MB there is plenty of room, compared to the max 100 or 200 characters limit for other specimen descriptors, but this is not explicitly asked for. These may be minor points, but I think the standard should be reasonably complete and detail-balanced before presenting it to the community for comment.
(5) In terms of extensibility of the format, should “Additional fields are strongly discouraged” really be the only thing we have to say? Are there any plans how to deal with potential revisions or extensions, beyond including a HDF5 version number?

>> I think there is no clear concept yet.

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

---

-------------------------------------------------
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]

Just a couple of quick comments.

1) I believe "human-readable" normally only refers to ASCII text files, as apposed to binary formats. Therefore HDF5 isn't human readable in this way - however it is an open format, and there much more easily readable than the straight binary POS or proprietary RHIT/HITS. Also the apth5 format is proposed as a "neutral" format, as apposed to the new .apt format from Cameca (AP Suite 6/IVAS6 APT format).

2) Conversion from POS isn't going to contain anything because it doesn't contain the required information. Conversion from EPOS is reasonable, but again, it is missing all the meta-data. I don't see an easy way to make filling these in automatic (which is practically the only way this will really work as a format). Maybe if it was linked with some kind of sample and instrument database..?

Otherwise I think I agree with most of your points and think it forms a good basis for an introduction and reasoning behind the process. 

It should probably mention open science and FAIR principals; this should be the community recommended standard for SHARING data, I think that's a key point.

Andy

---

From: atompr...@googlegroups.com <atompr...@googlegroups.com> on behalf of Markus Kühbach <m.kue...@mpie.de>
Sent: 22 June 2020 13:53

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

[Daniel Haley]

Hi All,

With three no votes, the voting is now closed. The committee has chosen
to not disseminate the document in its current form.

To help focus discussion, I would suggest that it may be valuable to see
the text of suggested amendments to the documentation wherever possible.


Thanks,

--Dan

[Bertrand Radiguet]

Hello all,

If I had had time to read my emails today, I would have voted option 2 (no dissemination), mainly according to Dieter's comment (1) and (2).

regards,

bertrand

[Daniel Haley]

Hi All,

I've not received any suggestions back from the current standard, which
would seem to suggest there are no changes to be made?

This doesn't seem consistent with the vote output, so there seems to be
a mismatch between the two. I'm unsure what changes are wanted here, as
to me the standard seems quite functional to implement. I note both
Erlangen and Inspico have stated they are happy with the current
implementation.

Thus there are several impetuses for completing this standard - firstly,
it is of interest to have something to show during the upcoming
workshop/seminar.

Secondly, the draft being not accepted for dissemination is currently
holding up the implementation of this by other groups. Un-jamming this
would be highly beneficial to consumers of this standard, and the
community at large. I'm a little reticent to hold a meeting at this
point, as there has been insufficient change from last time to warrant
this, but I will call one soon.

Thanks,

Daniel

[Anna Ceguerra]

Hi Dan,

I believe Erlangen has some concerns which have not been addressed. I am not in a position to give feedback right now given my current circumstances, but I suggest you talk to Peter directly.

Regards,

Anna.

---

From: atompr...@googlegroups.com <atompr...@googlegroups.com> on behalf of Daniel Haley <daniel...@materials.ox.ac.uk>
Sent: Wednesday, July 15, 2020 7:09:12 PM

To: atompr...@googlegroups.com <atompr...@googlegroups.com>
Subject: Re: Vote : Standards dissemination

--
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/gyorCL7EwMfj604WfB2Fxp?domain=groups.google.com.

[London, Andy]

Hi Dan,
Thanks for driving this forward. To be honest I've not had the time to look at this and my "TC time" has been spent on the up coming meeting.
There are things I'd like to comment on and to implement the MATLAB reader/writer - which when I worked on it previously raised quite a few issues to address. I just haven't had time yet.
Andy

-----Original Message-----
From: atompr...@googlegroups.com <atompr...@googlegroups.com> On Behalf Of Daniel Haley
Sent: Wednesday, July 15, 2020 10:09 AM
To: atompr...@googlegroups.com
Subject: Re: Vote : Standards dissemination

--
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/e2c34378-6a55-d0f1-083a-d91ff6b2b200%40materials.ox.ac.uk.