Midas_Toolkit: Adapter

[peterjamesnugent]

We can write the adapter to open a session of Midas but I am not sure how much use this will be as we cannot use it further or to open a specific file.

It might be that we use the adapter to point to a text file or folder where it can read/write.

When pulling the Midas export it is always going to be a single text file. The different features are split with a preceeding , e.g. NODES so it's fairly easy to determine what line nodes start and end on (by searching for the next *).

When pushing to the text files we should do it with several files to make the debugging simpler.

[peterjamesnugent]

The adapter should include a model settings tab for units. These can be eNums for the following@:

Length:

• m
• cm
• mm
• ft
• in

Force (mass)

• N (kg)
• kN (ton)
• kgf (kf)
• tonf (ton)
• lbf (lb)
• kips (kips/g)

Heat

• cal
• kcal
• J
• kJ
• Btu

Temperature

• Celsius
• Fahrenheit

[peterjamesnugent]

Units are defined in the MCT file as follows:

*UNIT    ; Unit System
; FORCE, LENGTH, HEAT, TEMPER
   KN   , M, BTU, C

[peterjamesnugent]

This is the pre-amble before any objects are created:

;---------------------------------------------------------------------------
;  MIDAS/Civil Text(MCT) File.
;  Date : 2018/11/27
;---------------------------------------------------------------------------

*VERSION
   8.7.5

*UNIT    ; Unit System
; FORCE, LENGTH, HEAT, TEMPER
   KN   , M, BTU, C

*REBAR-MATL-CODE    ; Rebar Material Code
; CONC_CODE, CONC_MDB, SRC_CODE, SRC_MDB
 ASTM(RC), Grade 60, ASTM(RC), Grade 60

This should be handled in the adapter.

[peterjamesnugent]

The key difference between the Lusas_Toolkit and the Midas_Toolkit is that no COM calls are required to create Midas Objects, therefore all methods should be stored in the Engine under the Convert > ToMidas folder.

[peterjamesnugent]

Given this some thought:

The MidasCivil Adapter should have the following objects that are similar to comlink objects:

• midasTextFile, this will be aList<string> that has been read from the MCT file (if it is available)
• directory, this will be a stringthat points to the folder the model is saved. This will be used in the Create methods to write to individual files such as NODES, ELEMENTS etc.

The read workflow will look something like this:

1. User has a model in MidasCivil they want to pull in to the BHoM
2. User exports an MCT file to the directory
3. User invokes read methods in the MidasCivil_Toolkit
4. The adapter reads the entire MCT file and individual segments will be sent to the Engine for the convert methods

The write workflow will look something like this:

1. The user wants to push BHoM objects in to MidasCivil
2. Adapter looks for an existing MCT or txt file to invoke methods
3. This file is broken in to seperate files for NODES, ELEMENTS etc. a. The benefit of this, is we are not awkwardly writing in to the main MCT file at odd line locations b. When we write object comparers they can neatly read the *NODE file to see what is already present c. The same goes for depedent types
4. When the information is pushed, the adapter invokes the engine for create methods (no COM link required)
5. This creates or appends to the series of text files produced
6. A method will be written to concatenate the text files together (sequencing is important here, e.g. ELEMENTS cannot come ahead of NODES because the elements reference the *NODES)

[peterjamesnugent]

When pushing properties that have been assigned there are two ways to achieve the correct assignments.

If the properties has a name (i.e. section properties, materials etc.)

• Push the property using dependency types, this includes assigning a unique name to the property
• Push the element with the property assigned
  • Within this method, go in to the SECTIONPROPERTY.txt file and modify the assignment list*

*We can write a generic method to modify the assignment list

If the properties do not have a name (loads, constraints):

• Push the property using dependecy types, assign to a load or boundary group - with the name of the object*
• Push the element and look in CONSTRAINT.txt for the constraint name, because the boundary group is assigned there: ; NODE_LIST, CONST(Dx,Dy,Dz,Rx,Ry,Rz), GROUP

When pushing constraints we should create all the boundary groups before pushing the individual constraints - it cannot be a dependecy type because it will just be a string

This is relevant to #7 #8 #9 #11

[peterjamesnugent]

This is largely complete, anything not covered has separate issues.