Model Compatibility Migration Guide#
The sgio.model refactor keeps a temporary compatibility layer so existing
projects do not break immediately, but new code should target the typed API.
Preferred API#
Import
LocationType,Model, andgetModelDimfromsgio.model.protocolsImport
StateandStateCasefromsgio.model.stateUse
CauchyContinuumModel.set_isotropy(),set_elastic(), andset_strength_constants()for solid-material updatesUse direct scalar attributes such as
ea,gj,ei22, andei33for named beam propertiesUse
get_matrix_component(),get_thermal_expansion(),get_section_matrix(),get_section_matrix_component(),get_center(), andget_axis_angle()for theory-bound quantitiesUse
sgio.iofunc.common.material_jsonfor material JSON codecsUse
sgio.iofunc.common.response_writersfor sectional-response writers
Legacy To New Mapping#
Legacy API |
Preferred replacement |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Deprecation Roadmap#
The compatibility layer is governed as follows:
API family |
Warning begins |
Planned removal |
|---|---|---|
|
|
|
|
|
|
String-based |
|
|
Model-level JSON and response-writer wrappers |
|
|
New functionality must go into the typed API only. The compatibility layer is frozen and should not receive new feature work.