Hi,
the zero value of activityltf simply means that element does not exist yet, so its contributions to the problem are not evaluated and assembled.
This may require some additional effort, for example, when you have nodes solely connected to inactive elements at particular time then these have to be supported or linked to other nodes, as they will receive no stiffness. Seems to me that this can be an issue in your model.

1. When an element gets activated, it uses the current displacements of it's nodes as the "initial displacement" that subtracted when computing strains.

2. If a DOF isn't connected to any (active) elements, then it will cause 1 line/row to be all zeroes in the stiffness matrix. This is a singular problem (but technically still solveable), and it will not work direct solvers (Cholesky, LU). There are several tricks around it
1. Using a CG-solver might work
2. PETSc has flags for adding small values on diagonal positions.
3. You could prescribe the DOF with a Dirichlet b.c. and turn off this b.c. when the connected elements are activated.

Dear Licui, you forgot to attach the file (you have to click the button after selecting the file, common mistake on the forum)

Hi,
I've done some simplified tests and the results is interesting. I used lspace of rectangular and ladder, lspacebb of ladder and lspace together with lwedge. The results shows different displacements are given for different elements. The rectangular one get symmetric results which are supposed to be, while there is a little difference for ladder elements of lspace and lspacebb, and the last one gets the worst values. (I've attached my input and output files below.)
Is that means element type or number will influence the results while Nonlinear Material and StructuralStatic are used?
One more question is whether displacements, strains or stress can be used for i.c.
Thanks a lot.

Hi,
Thanks for your great patience. Sorry to reply so late for some private bussiness.
I'm going to make my material better for oofem, and do some sensitivity analysis.
As for "initial conditions", is it meaningful for StaticStructural method? Boundary condition is impossible to change, but an initial one could be useful to determine a stiffness matrix at the beginning.
Thanks for your reply again.

Thanks for your patient reply again.
Do you mean initial stress/strain will not affect the stiffness matrix in elastic-solving step when a nonlinear material is used? Of course I can use "activityltf" to do it, but I don't know what the solvers do when new elements with old ones work together. The results of my tests is terrible. Even uphill displacements were given by the force of gravity.
Moreover, can you tell me something more about the way to use CG-solver?
Thanks a lot.

I'm glad that my work can do some help to OOFEM, and your answer is really helpful every time.
I noticed that you said we could change b.c. arbitrarily, so some tests were done to get aware of it. There is supposed to be an extra step for it, because any change of conditions during the time step will be ignored. Just like what I do, tests without b.c. get the same results as the ones whose b.c.s are canceled during the time step.
However, I'm still confused how the StaticStructural solver judes whether or not these conditions are activitied. In my tests it seems to choose a time point at the end of time step.
Thanks a lot.

StaticStructural checks if the BCs have activated/deactivated from the previous step, then renumbers the equations and all that when needed.
This is of course done at the target time, for when equilibrium is solved.
Doing any changes to BCs *within* a single timestep is wrong. If you need that high fidelity in your analysis, then you also need to use smaller time steps.
So, the BCs activation needs to change during the time step (after the start of the step, and before the end (target) time of the step).

----------

That is not even theoretically possible. "make displacement zero" === "constraint".  Constraining something without constraints?

---------

For debugging, please test each component separately. Use an existing (simple) material model, to run a minimal test (preferably 2 elements) that produces the problem, and we can help you find what could be wrong.

You sure like to write out everything out as scalar components, many of them just labeled "x1, x2, ... x9, a7, a8, a9". I have no idea what these represent, and neither would anyone else who reads the code.
All the familiar concepts are completely obfuscated; triple negations, random variable names.

    x3 = j1 * ( sigma22 + sigma33 - 2 * sigma11 );
    x3 = -x3 / x6;

    x4 = j1 * ( sigma11 + sigma33 - 2 * sigma22 );
    x4 = -x4 / x6;

    x5 = j1 * ( sigma22 + sigma11 - 2 * sigma33 );
    x5 = -x5 / x6;

    x7 = j1 * sigma12 / q;
    x8 = j1 * sigma23 / q;
    x9 = j1 * sigma31 / q;

Seems like this is something along the lines of " nu = sigma_dev * J1/sigma_vonMises; "
Why write out the components?!  These bugs would never happen if you stick with vectors
As far as I can tell, you mess up the Voigt order of x7, x8, x9.

This mess of variable names would reduce to something as simple and easy to read as:

    FloatArray sigma_dev, nu;
    const FloatArray &stress = status->giveStressVector();
    double hyd;
    // Keep the data in vector form.
    hyd = StructuralMaterial :: computeDeviatoricVolumetricSplit(dev, stress);
    p = -hyd;
    q = StructuralMaterial :: computeVonMisesStress(stress);

...
    answer.plusDyadUnsym(sigma_dev, sigma_dev, j1/q);

Of course, the strain and stress are unconditionally coupled together by the act of solving for equilibrium. If you don't want the stresses to influence  equilibrium (and thus displacements and strains), then I don't know what you want to solve for.

Locking nodes is just a means to make the problem solveable. It doesn't affect the solution at all compared to CG-solver.

1. Time step one, you have 1 layer of elements active. You obtain displacements for the first layer of nodes.
2. Time step two, you activate the second layer of elements. This second layer of elements use the solution from the first step as their initial displacements (stress free). Then you actually solve for the new mass and stiffness added by the second layer, and you get new displacements for all the nodes on the first and second layer.
3. Time step three, add another of new elements whose initial displacement are those from the solution from step 2. Apply the new mass and compute the new strains and stresses in all elements for all 3 layers.
4. And so on.

That's it. Just activityLTF on each element row.

Locking the otherwise unconnected nodes by B.C is just trick to get the linear sparse solver to work. It doesn't affect the solution at all.

Actually, I'm quite sure I already understand the problem perfectly well.

This is not at all relevant to the problem setup. Reality doesn't "know" what material model you intend to use.
So, whatever model you use, the boundary conditions, element activation etc. should of course be identical. Therefor, this point is a not a factor in the problem setup.

Yes. As I've said many times now, the BCs on the unconnected nodes are just there to make the problem non-singular so that direct solvers will work. ActivityLTF changes the output. The BCs on the nodes do not (if you apply it correctly).

No they shouldn't. This is an awkward, inconvenient way to solve a problem which is solved perfectly by using initial displacements for the newly activated element instead of doing what you seem to ask for.

1. The new layer of elements gets activated (and the release of a new layer of nodes above)
2. The starting values for all nodes are the displacements from the previous step. NOT ZEROED out. The stress/strain state of all the old elements are also preserved.
3. The newly actiaved elements will use the current displacements of the old nodes as their, interally stored, initial displacements:

strain = B * (displacements - initial_displacements)

The new elements will "start" with zero strain.

If you insist on trying to re-define the displacements of the nodes in each step (which would give identical solution to the procedure mentioned above) then you'll have to rewrite the solver. Of course, there is no point to this, since ActivityLTF is already simulates additive manufacturing in this manner.