NXenvironment

[sanbrock]

• Can it be used as /ENTRY/INSTRUMENT/ENVIRONMENT or only /ENTRY/SAMPLE/ENVIRONMENT?
• can an ENVIRONMENT list all independent controllers (for a scan) or only a single one?
• can an ENVIRONMENT contain measurement sensors?
• Also support parameters which may not be measured, like temperature could be simply RT (Room Temperature) without it being actually measured by a sensor.

[sanbrock]

PR #1414

[sanbrock]

Proposal:

• use of @default
  A) add to each group manually as proposed
  B) no need to add, because it is a NeXus conventions that all groups can have this attribute
  C) add this to NXobject and let all group inherit it
• NXidentifier
  A) use as a Base class which we add wherever needed
  B) make the Fields to Attributes and use this base class as super class. This allows attaching a single identifier to any group inheriting from this.
  C) same as B, but use nameType=partial, like identifier_serviceNAME, identifierNAME, and identifier_is_persistantNAME to support multiple IDs to add. E.g. identifier_experiment, identifier_collection, identifier_orcid, identifier_pdb
• NXfabrication
  features: vendor, model(@Version), serial_number, construction_year, capability, IDENTIFIER
• NXsensor
  added 'current' to the enum list of measurement types
  features FABRICATION
• NXactuator
  features: (short)name, type, FABRICATION, physical_quantity, pid, OUTPUT, TRANSFORMATIONS
• NXenvironment:
  added ACTUATOR
  added 'value' to support the case where no actual SENSOR, ACTUATOR is attached

[prjemian]

Check the nxdl.xsd Schema for the default attribute. If it is there for all fields and groups, it is not necessary to add the NXobject. Lots of work is done in the nxdl.xsd Schema.

…

On Sun, Sep 29, 2024, 1:47 PM sanbrock ***@***.***> wrote: Proposal: - use of @default <https://github.com/default> A) add to each group manually as proposed B) no need to add, because it is a NeXus conventions that all groups can have this attribute C) add this to NXobject and let all group inherit it - NXidentifier A) use as a Base class which we add wherever needed B) make the Fields to Attributes and use this base class as super class. This allows attaching a single identifier to any group inheriting from this. C) same as B, but use nameType=partial, like identifier_serviceNAME, identifierNAME, and identifier_is_persistantNAME to support multiple IDs to add. E.g. identifier_experiment, identifier_collection, identifier_orcid, identifier_pdb - NXfabrication features: vendor, ***@***.*** <https://github.com/Version>), serial_number, construction_year, capability, IDENTIFIER - NXsensor added 'current' to the enum list of measurement types features FABRICATION - NXactuator features: (short)name, type, FABRICATION, physical_quantity, pid, OUTPUT, TRANSFORMATIONS - NXenvironment: added ACTUATOR added 'value' to support the case where no actual SENSOR, ACTUATOR is attached — Reply to this email directly, view it on GitHub <#1451 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARMUMB7HPKLALZ7ADUX5RLZZBDMRAVCNFSM6AAAAABO437CEKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBRGQ2TSNJQHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[phyy-nx]

Use of default: B)
NXidentifier: instead of a new base class, NXidentifier, add to NXobject a set of identifier attributes. Useful for application definitions or for users wherever they want (like in #1486, but use attributes instead of a field
NXfabrication: ok following suggested edits
NXsensor: ok
NXactuator: ok following suggested edits
NXenvironment: ok

[phyy-nx]

Proposal:

Use of default: B)
NXfabrication: ok following suggested edits
NXsensor: ok
NXactuator: ok following suggested edits
NXenvironment: ok

The above is approved by vote in NIAC 2024

Not for this proposal:
@sanbrock please provide an implementation of identifier as described above that we can vote on