I slightly changed the code so the export of internal forces is easier to VTU (ParaView etc.). This should work on trusses and beams and it was tested on elements Truss3D, Beam3d, LiBeam3DNL. The idea is to export internal forces with local coordinate system. This is facilitated by outputting IST_BeamForceMomentTensor (7) with IST_X_LCS (146), IST_Y_LCS (147), IST_Z_LCS (148), e.g.

vtkxml tstep_all primvars 1 1 vars 4 7 146 147 148 stype 0

VTU files now contain point data; a truss element only end points, a beam element usually more points within its length since it needs to plot different deflected shapes by straight lines and various functions for internal forces.

Data post-processing in ParaView 5.10 is showed for tests/sm/beam3d_1.in, which is a 2D frame loaded with a force and a uniform distributed load. Solution is linear elastic and every beam is internally subdivided into 10 segments. Local coordinate system can be plot using Filters->Glyph and Glyph Type arrow. Every n^th point can be plotted so the local axes are at desired locations and not in every segment, see the attachment.

For example, to plot the shear force Vz, one needs to create a new vector Vz in Filers->Calculator as IST_BeamForceMomentTensor_ZZ * IST_Z_LCS . One can plot the diagram using Filters->Warp by vector, taking the new vector Vz. Coloring can be added. It is quite common to hatch (or fill) the diagram so it points to the correct finite element. This can be facilitated using Filters->Glyph with Glyph Type->Line.

Plotting bending momentum follows the same approach, multiplying IST_BeamForceMomentTensor_YZ * IST_Z_LCS . A user has even enough freedom to plot diagrams to directions as needed, e.g. diagrams for local normal forces on trusses can be plot in global coordinate system (using iHat, jHat, kHat) or local plane xy, xz. A filter in python can merge several of these filters, making plotting easier.

https://oofem.org/forum/misc.php?action=pun_attachment&item=526&download=0

Dear Mikael,
thank you for the explanation and quick fix. However, the above problem should be linear hence I never suspected iterations to be a problem. For some reason, introducing Newton's boundary condition with linear constitutive material causes iterations in TransientTransport solver (it was linear in a previous NlTransientTransportProblem solver). The unknown heat flow q=h(T-T_inf) depends on unknown T, h*T went in NlTransientTransportProblem to the left hand side and made the problem linear. It seems to me that T is now taken from previous iteration which renders the problem nonlinear or maybe the residuum is not evaluated correctly.

Attached is an input file, demonstrating this nonlinearity. If you change the solver by uncommenting 4th line, you see no iterations. Could you please have a look on that and made the problem linear again? It would speed up computation significantly.

Best regards. Vit

Dear developers,
I encountered inconsistency in TransientTransport solver when using sets. Let us take tmpatch21-8.in as a reference and change a solver to TransientTransport.

I can assign the same Newton BC either as "quadaxisym1ht 1 nodes 4 1 3 4 2 boundaryloads 2 2 4" or through set as "Set 3 elementboundaries 2 1 4". I obtain two slightly different results in node 1 (5.68352780e+00 vs. 5.68563857e+00) which I expect to be the same. Attached is the modified tmpatch21-8-tmp.in (un/commenting two lines gives two BC assignments).

Thank you for clarification/fix. Vit

Dear Mikael,
I have tested your TransientTransport solver and and I think this should indeed replace nonstationarytransportproblem and nltransienttransportproblem in a long-term view. I have just committed a few fixes:
- The solution of transient problem should always report variable at the end of the timeStep. Alpha is only for specifying intrinsic time, which is related to integration and solution. I changed output to be always at the end of timeStep, also in vtu export. If not doing so, coupled thermo-mechanical tasks would depend on alpha selection and time synchronization is broken.
- We need to support VM_Incremental. This applies for coupled tasks such as thermo-creep formulated in incremental form. With Borek, we reimplemented the original incremental calculation in DofDistributedPrimaryField :: giveUnknownValue() so we compute the increment when necessary instead of holding increment on DoFs.
- Several testing examples and benchmarks were updated to use this TransientTransport solver. I checked that results correspond to physics. TransientTransport supports all sets which is untrue for surface/edges in old solvers.

I, Vit Smilauer, agree that my existing and future contributions* may be licensed under: "LGPL2.1 or any later version"**
* Contributions sent to oofem.org or github.com/Micket/oofem
** By any newer version it means you would allow LGPL2.1 and newer versions of the license (at the option of users). (As we do right now but for GPL, see any header file). This addendum is a must, as we would otherwise risk becoming incompatible with other open source software.

6

(4 replies, posted in General Help)

Dear Xuejian,
I updated a fixed version of the zip and ctrl file. Instead of "boundaryLoads", the keyword has changed to bLoadNum.
Vit

Dear djd,
I have been developing the macro/micro problem at the same time of 1.9. release and, you are right, it does not work there. You need to download the devel version from svn, see http://www.oofem.org/en/miscellaneous/svn.html . You also find an example under tests/sm directory: macroLspace01.in and corresponding microMaterial01.in (put nmodules 1 and uncomment the line with VTK output to see the results). So far, there is no documentation for this coupled task. We still have to resolve multiscale implementation in OOFEM which may take some more time. The idea of the two-scale modeling relies on two OOFEM input files, which can be run independently and which can be debugged easier separately. You can assign any material to the microproblem, so far tested for elasticity and damage. The two-scale analysis works so far on a linear brick element. If you have any suggestions and ideas, they are welcomed.
Vit