Topic: "undefined dofManager" error in large model

In the model attached I want to perform a non-linear static structural analysis of a large shell model.
Before to define the loads, I noticed a reading error in OOFEM:

____________________________________________________
           OOFEM - Finite Element Solver
        Copyright (C) 1994-2014 Borek Patzak
____________________________________________________
Total number of solution steps     10
_______________________________________________________
Error: (domain.C:459)
In Domain::oofem::Domain::giveNode, number: 1:
undefined dofManager (1020001)
_______________________________________________________
No backtrace available
Total 1 error(s) and 0 warning(s) reported
oofem exit code 1


I cannot understand to what is related this error, can you help me?

Secondly, I would like to know if a discontinuous numbering of nodes and/or elements is a problem in a input deck.

thanks,
Giovanni

Re: "undefined dofManager" error in large model

The nodes and elements may be numbered arbitrarily (though they need to be unique). They will be renumbered internally by OOFEM after the input file is read, so the first node will always be node number 1 when calling Domain::giveNode.
It is definitely a bug in OOFEM (even if you make mistakes in the input file, you should at worst only get an error message from the input record, which would be much more helpful).


However, without any backtrace, or any input file, it's impossible to say what went wrong here.

Re: "undefined dofManager" error in large model

I'm really sorry, I noticed only now that the attchment was missing.
Here you are the input deck, I zipped it 'cause the forum prevents too large files.

many thanks in advance,
Giovanni

Post's attachments

7pianiOOFEM.zip 575.75 kb, 1 downloads since 2014-10-29 

You don't have the permssions to download the attachments of this post.

Re: "undefined dofManager" error in large model

You are using your own user elements here, which I don't have access to, so, unfortunately, I can't pinpoint the problem here.
When you are loading user elements like these, memory corruptions from the dlls can spread to OOFEM, so that could be a reason here. It could be a simple misunderstanding about memory deallocation from calling the UEL routine.

What I can tell you is that the nodal coordinates seem broken. You specify your elements as "UEL springs" but many nodes overlap, meaning you won't really have a well defined direction of your springs.

For example, these nodes, used by element 5040:

node 1530423 coords 3 9550 7395 3000
...
node 1570209 coords 3 9550 7395 3000

have the same coordinates.



Edit: Also, your input file is to short. I switched from your elements to normal springs and I get:

Error: (/home/micket/projects/oofem/src/oofemlib/oofemtxtdatareader.C:101)
In giveInputRecord:
Out of input records, file contents must be missing

I'm not sure what your abaqususerelement is doing. Is it accessing giveNode() in it's initializeFrom implementation? (It shouldn't)

Re: "undefined dofManager" error in large model

Thank for the reply. The model is purposely written with 2 nodes in the same place, I use UEL elements that connects the walls, and this springs are initially of zero-length (and their DOFs are uncoupled). So the coordinates are not broken.

I have already post the code in http://www.oofem.org/forum/viewtopic.php?id=1468 , I attach now an updated version.
giveNode() is implemented in initParams(), but not in initializeFrom.

Finally, can you please send me the file with normal springs? just to check the missing parts without errors.

many thanks,
Giovanni

Post's attachments

UELinterface.zip 5.16 kb, 4 downloads since 2014-10-29 

You don't have the permssions to download the attachments of this post.

Re: "undefined dofManager" error in large model

Before all the initialization of all components is done, components may not really access the domain at all (which is what you do in initParams(), which you call from initializeFrom). You might not get away with it when you have sequential numbering, but the real solution would be to avoid this type of operations this early.

Initialization is done in stages;
1. initializeFrom    <-- Reads all the input records. You may also set up basic things if necessary.
2. postInitialize     <--- Runs after initializeFrom is completed for all components
3. checkConsistency   <--- Runs after all initialization is done, verifies that everything is properly set up (shouldn't modify the components, just check that stuff works).

If you move this section

        if (this->coords.giveNumberOfColumns() == 0 || this->coords.giveNumberOfRows() == 0)
        {
            this->coords.resize(this->numberOfDofMans, this->mcrd);
            for (int j = 0; j < numberOfDofMans; j++)
            {
                Node *dm = this->giveNode(j + 1);
                for (int i = 0; i < mcrd; i++)
                {
                    this->coords(i, j) = dm->giveCoordinate(i + 1);
                }
            }

        }

to the function "AbaqusUserElement::postInitialize()", then it should work. So:

void
AbaqusUserElement :: postInitialize()
{
    NLStructuralElement :: postInitialize();
    if (this->coords.giveNumberOfColumns() == 0 || this->coords.giveNumberOfRows() == 0)
        {
            this->coords.resize(this->numberOfDofMans, this->mcrd);
            for (int j = 0; j < numberOfDofMans; j++)
            {
                Node *dm = this->giveNode(j + 1);
                for (int i = 0; i < mcrd; i++)
                {
                    this->coords(i, j) = dm->giveCoordinate(i + 1);
                }
            }
        }
}

Before accepting your code into OOFEM, there are a few things I've like to see you clean up;
1.

        result = IR_GIVE_FIELD(ir, this->nCoords, _IFT_AbaqusUserElement_numcoords);
        if (result != IRResultType::IRRT_OK)    OOFEM_ERROR("'coords' field not defined or not correctly formatted");

This is not necessary. The IR_GIVE_FIELD already takes care of error reporting

2. If I remember correctly, you should be able to simplify "AbaqusUserElement::giveDofManDofIDMask" to just the user-supplied dof array: "answer = this->dofs"

3. Add the missing stuff in "giveInputRecord"

4. Indentation and coding style ( http://uncrustify.sourceforge.net/ )

5. Documentation in doxygen style (see other classes in OOFEM)

Post's attachments

giovanni.zip 682.49 kb, 4 downloads since 2014-10-29 

You don't have the permssions to download the attachments of this post.

Re: "undefined dofManager" error in large model

Many thanks, I launched it and the reading is fine (I added a "#" to the final empty line to work, don't know exactly why). It hangs with 100% cpu utilisation, tomorrow I'll try with a smaller model.

I'll do the modifications you required asap, I'm glad to see the interface integrated in oofem.

I noticed a strange thing in my build; with your modified input (normal springs) I get:

____________________________________________________
Total number of solution steps     10
_______________________________________________________
Error: (floatarray.C:774)
In oofem::FloatArray::normalize:
cannot norm receiver, norm is too small
_______________________________________________________
No backtrace available
Total 1 error(s) and 0 warning(s) reported
oofem exit code 1

maybe I have to update from the git repo. I also modified in the input (line 48899) the number of the first UEL element from 0 to 8231.

thanks again,
Giovanni

Re: "undefined dofManager" error in large model

Yes. With springs require a length to determine the direction. I commented that out just to get passed the initialization step, but the simulation can't work like this (since the nodes overlap).

Re: "undefined dofManager" error in large model

I checked why the file is to short. You have not entered a load time function. Adding an additional # would not fix that (those are ignored anyway).

Re: "undefined dofManager" error in large model

I'm doing some tests, and I have just a trivial difficulty: I'm writing the load, and it seems that OOFEM would like to have the a continuous numbering of BCs and crossections. In domain.C I found:

        if ( ( num < 1 ) || ( num > nload ) ) {
            OOFEM_ERROR("Invalid boundary condition number (num=%d)", num);
        }

but I need a numbering like this (nbc=18603):

BoundaryCondition 1 loadTimeFunction 1 prescribedvalue 0.0
# nodal loads
NodalLoad 1500001 loadTimeFunction 2 Components 6 0 0 -0.0612439468085106 0 0 0
...

You said

The nodes and elements may be numbered arbitrarily (though they need to be unique).

there are any reasons this has not been done also for BCs and crossections? may I have necessarily to change bc numering?

thanks,
Giovanni

Re: "undefined dofManager" error in large model

Mesh modifications leads to element and node removal, so arbitrary numbering is particularly usegul there. Thatscthe only reason

12 (edited by johnnyontheweb 01-11-2014 21:48:53)

Re: "undefined dofManager" error in large model

3. Add the missing stuff in "giveInputRecord"

Can you please explain what do you expect to be written in "giveInputRecord" other that the lines already present?

Secondly, I tried to update with the current version from git, and I get the following errors on compiling:
1 - EquationID identifier not declared
2 - giveDof id not included in oofem::DofManager
3 - in giveDofManDofIDMask, answer is not declared

have you got some hints?

thanks

Re: "undefined dofManager" error in large model

I believe there were some of the input fields that were not written in the DynamicInputRecord (and a comment in the code that also indicated that).

1. EquationID is no longer in use. You should be able to get rid off that in your code easily.

2. In your code, whenever you called "giveDof(this->dofs(i))" it was a bug. It only worked for you because the first Dof happened to be D_u, which happens to have the value 1.
You should have been calling "giveDofID(this->dofs(i))".  I removed giveDof() because code may not explicitly depend on the order of the Dof storage (it might change if there are lagrange multipliers and similar things).

3. I'm not sure what you mean. I guess it's because of 1. (you should delete that EquationID parameter since it doesn't exist anymore).

14 (edited by johnnyontheweb 03-11-2014 22:48:38)

Re: "undefined dofManager" error in large model

Thanks for the help, I applied all the corrections needed in the code and it works fine.
Now I need some time to make the correct code formatting.

Just a remark: the name of the function "giveDofID" you cited is "giveDofWithID".

One more thing: in abaqususerelement.h I had to write:

    protected:
        virtual void computeBmatrixAt(GaussPoint *, FloatMatrix &, int = 1, int = ALL_STRAINS) { };    // this had to be set to avoid "C2259: cannot instantiate abstract class" compiler error

The procedure "computeBmatrixAt" should not be in the UEL interface, but it can be used however in a future interface for UELMAT. Can the presence of that declaration be not compulsory?

Finally, running my original model I get:

_______________________________________________________
Warning: (zznodalrecoverymodel.C:194)
In ZZNodalRecoveryModeloofem::ZZNodalRecoveryModel::recoverValues:
some values of some dofmanagers undetermined
[1 2 5 ]
_______________________________________________________

Is it a symptom of lability?

Thanks

Re: "undefined dofManager" error in large model

Since this is a very special element, you will need to overload computeBmatrixAt and just give some warning. The B matrix is mostly used for computing the stiffness matrix, but your element overload this routine directly so it wont be called anyway.

Almost all elements have a B matrix to compute, so we rather have it in the base class, and the few exceptions (like UEL) just have to spit out some errors if it is ever called instead. This is what elements have to overload if they are going to inherit from structural element.

The same goes for many other routines, like giveIPValue, for which there probably can't be any reasonable output from UEL.
You are also using ZZ nodal recovery, and I'm not sure if UEL could ever support this. If you have a node that is only connected to your UEL, then there just isn't any stress to compute, so the node would be without any values. VTK will export it as zeros.



Also, having looked at the code again, I think you should simplify (and generalize) the code you have

            // init U vector
            int z = 0;
            for (int i = 1; i <= this->numberOfDofMans; i++)
            {
                DofManager *dmgr = domain->giveDofManager(dofManArray.at(i));
                for (int j = 0; j < nCoords; j++)
                {
                    Dof *dof = dmgr->giveDof(this->dofs(j));
                    this->U(z) = dof->giveUnknown(oofem::ValueModeType::VM_Total, tStep);
                    this->DU(1, z) = dof->giveUnknown(oofem::ValueModeType::VM_Incremental, tStep);
                    z++;
                }
            }

This will be incorrect if you have slave dofs or nodal local c.s.
You should be calling

            // init U vector
            this->computeVectorOf(VM_Total, tStep, U);
            this->computeVectorOf(VM_Incremental, tStep, DU);

16 (edited by johnnyontheweb 18-11-2014 13:29:53)

Re: "undefined dofManager" error in large model

Thanks a lot, I'm doing some tests. I'll let you know when everything is ok.

17 (edited by johnnyontheweb 18-12-2014 10:55:00)

Re: "undefined dofManager" error in large model

I'm now testing the modal response (EigenValueDynamic) with the AbaqusUserElement. I used the lines you suggested:

            // init U vector
            this->computeVectorOf(VM_Total, tStep, U);
            this->computeVectorOf(VM_Incremental, tStep, DU);

Is it correct that computeVectorOf(VM_Total, tStep, U) gives back the eigenvectors? (in the code I skip this instruction if the eigen analysis is perfomed, because the eigenvector matrix is not initialized yet).

Moreover, the line with computeVectorOf(VM_Incremental, tStep, DU) causes a memory error, because the eigen analysis cannot handle a VM_Incremental request.

To sintax what I'm saying: in AbaqusUserElement I manually initialize U and DU to zero if the analysis is EigenValueDynamic. This will be a problem: I'm guessing if I could run a modal analysis on a deformed structure, after a nonlinear static analysis for example. I cannot still know how to set the input deck to do that, but I'm working on it.

18 (edited by johnnyontheweb 18-12-2014 12:31:08)

Re: "undefined dofManager" error in large model

To clarify the previous post, the actual code in giveInternalForcesVector is:

        EngngModel* model = this->giveDomain()->giveEngngModel();
        EigenValueDynamic* evd = dynamic_cast <EigenValueDynamic*> (model);
    if (evd == NULL){
        // init U vector
        computeVectorOf(VM_Total, tStep, U);
        FloatArray tempIntVect;
        // init DU vector
        computeVectorOf(VM_Incremental, tStep, tempIntVect);
        this->giveDomain()->giveClassName();
        DU.zero();
        DU.addSubVectorCol(tempIntVect, 1, 1);
    }
    else
    {
        U.zero();
        DU.zero();
    }

Finally, Borek said that, in order to be able to perform a eigen analysis after one of another type, the eigen solver must be adapted.

Re: "undefined dofManager" error in large model

I think it should be possible to extend the eigen value solver in an acceptable way to have it also be able to return "VM_Incremental".
That would be much nicer than having the element do type checking (including other components break modularity of the code, so I try to avoid that if possible).
Also, the only reason you see this problem appear is because of

        if ( !hasTangent() )
        {
            // use uel to calculate the tangent
            FloatArray forces;
            giveInternalForcesVector(forces, tStep, 0);
        }

that you use to ensure that the tangent is available (this happens if the tangent is requested before the internal forces).
You could design the code to have a support function

        if ( !hasTangent() )
        {
            initialTangentComputation(tStep); // This function would just call uel with DU = U = 0.
        }



For you second issue, switching analysis type (going from a static problem to an eigen value problem) is indeed not completely trivial.
By design, the engineering model is the main controlling loop, and cannot easily be switched during the analysis. I can't see any simpler way than what Borek suggests. Creating some sort of "AnalysisSequence" engineering model, and then mapping over the solution as the initial guess from the previous solution (as well as strains and stresses if necessary).

Re: "undefined dofManager" error in large model

Thank you Mikael. For the uel interface problem, I'll do it easily; moreover, abaqus can be called with other flags to require only the stiffnesses, even in the case of already deformed state. I'll send you the corrected code.

For the second problem, the first thing to do is to have 2 different variables to store eigenvectors and displacements. This will solve many needs related to modal analysis, but your solution is cleaner.

Re: "undefined dofManager" error in large model

It's not as simple as just storing another vector. You need to change the Engineering model. All the logic for how to solve the time step would need to completely change, and changing form a static solver to a dynamic solver would make the solver very convoluted. Better to have a clear boundary where the final output from the statis solver is the initial conditions for the dynamic solver.

Perhaps we should push for the Python interface more in this case. It was intended to be used for more specialized analysis (but I'm not sure if anyone is using it).

Re: "undefined dofManager" error in large model

is there any reference for Python other that this?

Re: "undefined dofManager" error in large model

Not that I know of, unfortunately.
If you where to use the Python bindings, you would surely find a few places where we aren't exposing enough functionality (since we haven't been testing it extensively yet).