Support Boundary Conditions and Loads

[Joroks]

I'm currently working with a dataset where the Displacements and the loads are stored in the .inp file alongside the grid. Currently it's not possible to read them through FerriteMeshParser.

I'll try to get this to work, however, I'm not sure how to best output the resulting Boundary Conditions and Loads, as the Ferrite Grid struct can't carry this information.

Maybe this should just be a seperate function that can read the boundary conditions and loads? Should this function then return a FerriteMeshParser specific struct that has the boundary condition information?

[KnutAM]

While not the core purpose of this package, I think this could be a useful addition for users if we can find a nice way which is stable and doesn't add too much code (to avoid the additional maintenance load).

What concerns me a bit is that the Abaqus input file has a lot of options, so I'm guessing there will be many corner cases to support, which perhaps will be tricky. I'm for example not sure how many different versions there are in the input file for specifying the boundary loads / conditions which would need to be handled?

Those challenges aside, spontaneously, I see to possible paths

1) Provide an extra function to parse this information, and return that as a custom struct which contains the data for adding loads 2) Rewrite the parser to contain all data from the input file in an AbaqusInp struct, which can then be used to extract a mesh from, or other data relevant for boundary conditions.

I do not think we should start overloading Ferrite types though, e.g.

Ferrite.add!(ch, bc::AbaqusBC)

is probably not a good idea.

But if you have some nice ideas how to implement this, I'd be happy to review and give feedback on a PR.

There was some work along these lines some years ago, see https://github.com/Ferrite-FEM/Ferrite.jl/pull/216.

[Joroks]

Defining an AbaqusInp struct seems like the way to go. I imagine this would be a vector of AbaqusKeyword with

struct AbaqusKeyword
    keyword::String
    parameters::OrderedDict{String, Any}
    data::Matrix{Any}
end

[KnutAM]

I like your idea with the keyword, if it would be possible, perhaps we could represent the input file (except the grid/mesh part) as a nested [Abstract]Dict.

In this package, we already have the RawMesh (https://github.com/Ferrite-FEM/FerriteMeshParser.jl/blob/main/src/rawmesh.jl) (which is designed such that hopefully use it for different formats (e.g. comsol or ansys), even if that isn't tested / implemented yet). Probably we should parse directly into this at least for the mesh part, but the rest could perhaps be a "metadata" field, e.g.

struct InputData
    format::Symbol # In this case :abaqus
    mesh::RawMesh
    metadata::Dict{Symbol} # `format`-dependent metadata
end

[Joroks]

I like your idea with the metadata, however, I don't think that it should be a Dictionary but either a Vector{Pair{Symbol}} or simply a Vector{Any}. Maybe even just Any?. For the .inp file, it's possible to have multiple instances of the same keyword and I belive the order of the keywords can be important as well.

We probably shoudn't limit the type of the metadata, as the metadata is format dependent and we don't know what exactly this would look like for different file formats.

[KnutAM]

I didn't mean that the keys would be Abaqus keys directly, but to structure the data so that you can request the specific data you want. So for e.g. this file, we would have keys :materials, :steps, and potentially :assembly and :parts depending on the final design (for supporting multi-part / instance files it might actually make more sense to read all into one datastructure first (each item that defines a mesh would not change, but for two instances of the same mesh, we could do this rather efficiently then). I don't think we need to care about ordering at the top level, but we could always use an OrderedDict.