<femdata/> needs to be specific to use cases

[DrCaFr]

Discussion of 2020-12-10 work group meeting revealed that <femdata/>-element needs to be specific to use cases.

I suggest starting the investigation with collecting use cases. — e.g. by writing below one comment per use case?

---

Cited from @mweinert611's protocol (2020-12-17): It becomes obvious that there seem to be 2 types of use cases so far for <femdata/>.

• Use case 1: the Pre-Proc writes the <femdata/> block – in this case, design changes drive updates in the <femdata/> written by the Pre-Proc
  ⇒ CF, 2021-01-07: For my understanding, this use case contains the below mentioned ones Identify discretization objects for modification, Identify objects of heat affected zone, Remesh heat affected zone, and Identify connected objects of flange partners if not even more.
• Use case 2: a downstream activity (e.g. fatigue) writes <femdata/> — in this case, the Pre-Proc ignores the <femdata/> as compatibility cannot be guaranteed for design changes.
  ⇒ CF, 2021-01-07: I doubt that this can be decided so globally. I'd recommend investigating more specific use cases (such as those mentioned below :wink:.)
• If a downstream activity needs the Pre Proc to output certain <femdata/>, it must be described in the related software manual / documentation
  → then the Pre-Proc SW vendor can (decide to) create <femdata/> per use case 1
  ⇒ CF, 2021-01-07: I agree: Downstream systems need to document precisely, which information for which use case they need to find in <femdata/> element.
• A small team (Nick E, Tim G, Stephan H, and Carsten F) will align in more detail and prepare a proposal for the next WG meeting.

---

Nick (@economidis-nick), Tim Guirguis (@TimGuirguis), Stephan Haas (@StephanHaasECS) & Carsten (@DrCaFr) volunteered to supply the working group with a proposal upon next meeting.
⇒ CF, 2021-01-07: WebCos were scheduled for 2021-01-08 and 2021-01-22.

---

χMCF-3.1-documentation contains following example in sec. 5.2.1.1:

<connection_0d>
    ...
    <femdata>
        <NASTRAN>
             <entity>
                 <TYPE>
                     CQUAD
                 </TYPE>
                 <ID>
                     12345-12356
                 </ID>
             </entity>
        </NASTRAN>
    </femdata>
    ...
</connection_0d>

---

What kind of objects are relevant for <femdata/>, anyway?
First of all, we think of finite elements which are supported by FE solvers, such as bars, hexahedra, CWELDs etc. "Virtual" connector elements, known to preprocessors only, are not relevant, here.
In addition, such solver entities, which are referenced by finite elements, are relevant, like nodes (grids), properties, materials etc.

Within the finite elements, we can distinguish between following kinds of elements:

• elements modeling connections between parts of the mechanical structure, such as RBEs (spiders), bars, shells, solids plus solver specific elements such as CWELDs, etc.
• elements modeling parts of the mechanical structure, such as shells and solids. — And beyond these
  • elements not influenced by connections, at all (despite from becoming member of the load path)
  • elements influenced, e. g. heat affected zone.

_:heavy_checkmark: 2021-01-27: Paragraph transported to Word file version 3.1.1.

---

Hence, what about introducing a mandatory use_case attribute to the <femdata>-element, e.g. <femdata use_case="USE_CASE_NAME">?
Use cases names and their semantics would be defined in χMCF-documentation – standardized, but easily extensible, since no syntax change appears to be necessary when adding new use cases.
In order to allow more than one use case per connection, multiplicity of <femdata>-element needs to be increased from 1 to 1-*.
Receiving systems could emit a warning when reading an unknown use case.
Writing systems are responsible for consistent data — i.e. they must not export a "piped-through" <femdata>-element of an unknown use case, containing invalid element IDs etc.
Idea: Object lists imported from <femdata>-elements could be represented as sets, such that a) users easily understand what happens and b) existing algorithms care for updating object lists upon FE element deletion etc.

[DrCaFr]

Use Case Identify discretization objects for modification:

1. Preprocessor A exports a NASTRAN deck with CWELDs and a χMCF file with CWELD IDs in <femdata/>. These CWELD discretize spot welds.
2. Preprocessor B imports both files. Now, some of the spot-welds are to be discretized by HEXAs. Hence, corresponding CWELDs need to be deleted (probably, together with their properties, materials, nodes). Thus, preprocessor B relies on correct identification of CWELDs for each spot weld.

---

Remark:
VDA FAT AK 27's FATXML describes how to embed FATXML-data into solver decks by means of specific solver cards / key words:

• NASTRAN, OptiStruct — METADATA
• PAM-CRASH — CDATA
• PERMAS — $COMMENT
• Radioss — /PRIVATE/METADATA/FATXML
• Abaqus — **XML
• LS-DYNA — *DATABASE_FATXML

χMCF-data could be embedded into solver decks, similarly.

---

Discussion 2021-01-08: This use case is not in the scope of χMCF format.
It is recommended to transport solver decks without discretized elements in, accompanied by χMCF files without <femdata/> in.

@economidis-nick: I think, this decision needs to be documented in the χMCF standard document. What's your opinion?

_:heavy_checkmark: 2021-01-27: Decision transported to Word file version 3.1.1.

[DrCaFr]

Use Case Identify objects of heat affected zone:

1. Preprocessor A exports FEMFAT data with the elements of heat affected zone enumerated in <femdata/>.
2. Preprocessor B imports both files (mesh & χMCF). It is used to convert the data to NASTRAN format. However, elements of heat affected zone must not be deleted, here. (Despite the fact that they are mentioned in <femdata/>!)

[DrCaFr]

Use Case Remesh heat affected zone:

1. Preprocessor A exports FEMFAT data with the elements of heat affected zone enumerated in <femdata/>.
2. Preprocessor B imports both files (mesh & χMCF). It is used to remesh one of the parts. Hence, some of the element IDs mentioned in <femdata/> become invalid and need to be replaced by new element IDs.

[DrCaFr]

Use Case Identify connected objects of flange partners:
(This is similar to use case Identify objects of heat affected zone.)

1. Preprocessor A exports χMCF data with the structure elements to be connected (e.g. found by projection) enumerated in <femdata/>.
2. Preprocessor B imports both, mesh & χMCF. It is used to modify the connection, but not the structure. Hence, structure elements must not be deleted, here. (Despite the fact that they are mentioned in <femdata/>!)
   However, if e.g. location of connection is adjusted, lists of connected structure elements may need to be updated.

[DrCaFr]

A χMCF file containing <femdata/> always refers to one specific solver deck (due to element IDs etc. used for referencing).
If e.g. element IDs get renumbered, the χMCF file becomes void / needs to be re-created.

@economidis-nick: I think, this needs to be mentioned in the χMCF standard document. What's your opinion?

_:heavy_checkmark: 2021-01-27: Aspect transported to Word file version 3.1.1.

[DrCaFr]

Use Case Usage of <femdata/> for postprocessing.

@economidis-nick reports that some users consider transporting relation between connector elements and discretization elements through solvers (from input to result file), similar to FATXML manner.

Kosmas reports that some solver systems, e.g. FEMFAT, change connectors (shape, location, meta data). Changes can be applied by both, the solver and the user. This information is currently not transparent to down-stream systems.

[DrCaFr]

What are the typical requirements of different kind of solvers, especially fatigue solvers, to <femdata/>?

• FEMFAT: Currently, relevant data is best kept in <appdata/>, because it is not of the "reference type", which <femdata/> is addressing.

Other solver vendors to be interviewed about their needs.

---

@DrCaFr: 14 days after "RFC", no feedback received from any participant of the previous AK 25 meeting.

[DrCaFr]

Discussion of 2021-01-08 revealed that <appdata/> definition on page 33 needs some review wrt. the word "export":

Content of <appdata/> is regarded to be "private property" of the corresponding application. However, in the sense of "best practices", it is recommended, but not required, • […] • to import, store and export <appdata> of 3rd party applications on block – to prevent loss of data in applications allowing export,

In case that a connector gets modified in a preprocessor, the preprocessor cannot know (from the standard), how to update <appdata/> of an "alien" system due to lack of documentation of its syntax and semantics.

_:heavy_checkmark: 2021-01-27: Comment transported to Word file version 3.1.1 as a comment, which needs to be processed.

[DrCaFr]

Decisions of 2021-01-22:

1. Due to missing demand from user's side, χMCF format will not be changed.
2. Though syntax is exactly described, semantics of <femdata/> remains fuzzy.
3. @economidis-nick and @DrCaFr care for extracting discussion results from this issue to provide some hints in the next update of the standard document.
   :construction: 2021-01-27: Work in progress.
4. Apart from this, specific agreements e.g. between preprocessor and solver/postprocessor can be made to support specific use cases.
   _:heavy_checkmark: 2021-01-27: Item 4 transported to Word file version 3.1.1.

[DrCaFr]

I would say, section

5.2.2.1 Reasoning about <femdata/>

is ok so far and suggest accepting all respective changes to the Word file and closing this issue.

[DrCaFr]

Suggestion accepted. Issue closed.