Thanks for the reply, I have the stack trace.

     oofem.exe!oofem::Logger::writeELogMsg(oofem::Logger::logLevelType level, const char * _func, const char * _file, int _line, const char * format, ...) Line 280    C++
     oofem.exe!oofem::FloatArray::assemble(const oofem::FloatArray & fe, const oofem::IntArray & loc) Line 543    C++
     oofem.exe!oofem::TR_SHELL01::giveCharacteristicVector(oofem::FloatArray & answer, oofem::CharType mtrx, oofem::ValueModeType mode, oofem::TimeStep * tStep) Line 132    C++
     oofem.exe!oofem::EngngModel::giveElementCharacteristicVector(oofem::FloatArray & answer, int num, oofem::CharType type, oofem::ValueModeType mode, oofem::TimeStep * tStep, oofem::Domain * domain) Line 1194    C++
     oofem.exe!oofem::EngngModel::assembleVectorFromElements(oofem::FloatArray & answer, oofem::TimeStep * tStep, oofem::CharType type, oofem::ValueModeType mode, const oofem::UnknownNumberingScheme & s, oofem::Domain * domain, oofem::FloatArray * eNorms) Line 1112    C++
     oofem.exe!oofem::EngngModel::assembleVector(oofem::FloatArray & answer, oofem::TimeStep * tStep, oofem::CharType type, oofem::ValueModeType mode, const oofem::UnknownNumberingScheme & s, oofem::Domain * domain, oofem::FloatArray * eNorms) Line 882    C++
     oofem.exe!oofem::NonLinearStatic::assembleIncrementalReferenceLoadVectors(oofem::FloatArray & _incrementalLoadVector, oofem::FloatArray & _incrementalLoadVectorOfPrescribed, oofem::SparseNonLinearSystemNM::referenceLoadInputModeType _refMode, oofem::Domain * sourceDomain, oofem::TimeStep * tStep) Line 853    C++
     oofem.exe!oofem::NonLinearStatic::proceedStep(int di, oofem::TimeStep * tStep) Line 471    C++
     oofem.exe!oofem::NonLinearStatic::solveYourselfAt(oofem::TimeStep * tStep) Line 345    C++
     oofem.exe!oofem::EngngModel::solveYourself() Line 562    C++
     oofem.exe!oofem::NonLinearStatic::solveYourself() Line 338    C++
>    oofem.exe!main(int argc, char * * argv) Line 286    C++

However, I tried to figure out how to solve: if there are no contributions, I forced to avoid to assemble in FloatArray :: assemble:

void FloatArray :: assemble(const FloatArray &fe, const IntArray &loc)
// Assembles the array fe (typically, the load vector of a finite
// element) to the receiver, using loc as location array.
{
    int n = fe.giveSize();
#  ifdef DEBUG
    // if ( n != loc.giveSize() ) {
        // OOFEM_ERROR("dimensions of 'fe' (%d) and 'loc' (%d) mismatch", fe.giveSize(), loc.giveSize() );
    // }

#  endif

    if (n == loc.giveSize()) {
        for ( int i = 1; i <= n; i++ ) {
            int ii = loc.at(i);
            if ( ii ) { // if non 0 coefficient,
                this->at(ii) += fe.at(i);
            }
        }
    }
}

So, the section "#  ifdef DEBUG" is no more used. Do you think it could be right? I'm making a simplier example to check results.

(sorry, at this point this topic should be in Developed discussion...)

Thanks

I absolutely agree, I'm changing TR_SHELL01 :: giveCharacteristicVector as you suggested:

    if (aux.giveSize() == loc.giveSize())     answer.assemble(aux, loc);

However, with a simpler example (see attachment), the code works but gives strange results.
Can you please have a look to the attached input deck, to see if it's wrong in any part? The model represents 2 wall not connected each other but both bounded at 2 base nodes.

thanks a lot

I tried running your new input file, and the problem is the tangent is singular. More specifically, the membrane part doesn't seem to be capable of computing the secant matrix requested, and returns a zero matrix. I can't find a good reason for this though, and I'm currently debugging it.

Thanks for your help; if I understand well, to see immediatly the changes I have to pull from https://github.com/Micket/oofem ?

Thanks, I downloaded corrected files and they work fine. I had to comment out some functions which are in your git repo and not in oofem.git; for the rest of the changes I'll wait your merge.

Only one last question: can you confirm that in OOFEM there aren't any quadrilateral shell (4 node plate + membrane) element? I dig in the manual, only 3 node shells seems to be available.

Thanks, I has already read that topic before posting, but to me the Quad1MindlinShell3D elements are not working properly; now I'll do some test with the flag "reducedintegration".

That must be the result of a bug in quad1mindlin.
But without either input file or stack trace from a debugger, I cannot help to debug it any further than that.

I've located the problem, but there are some complications. I can fix it, but none of the possible solutions are really that attractive.
I will make a quick.

Just for reference;
The problem stems from the elements local coordinate system, in combination with plate+membrane element.
Since many elements want to separate unknowns into groups (for example, velocity + pressure, or displacement + rotations), I added convenient functionality to request unknown vectors by specifying dof ids.
However, the implementation of the global to local coordinate system fails to take into account the anything but the default dof ids.
Adding this support would be possible, but it would also add a whole lot of code for many elements, and I'd like to keep them as simple as possible.

I'm thinking this might be an issue introduced by some local changes that you have introduced.
From what I can tell from the error message:

error C2228: the element to the left of '.reset' must have a class, structure or union C: \ oofem \ src \ sm \ quad1mindlinshell3d.C 95 1 sm

"computeGaussPoints" is nearly identical in all elements, and the "reset" function is used in all of them.

You need not worry about my comments about the default dof IDs. This is just me having an open document on these issues.

I worked around it for now, by using the function that takes all the elements DOFs. I added the warning in case any other element tried to do the same in the future.

The fact that I just had to make a fix to make quad1mindlinshell3d work at all says quite a bit of the stability; There are no tests for it, and by that meassure, I would have to call it unstable. I would not recommend using it for analysis without making a few tests to see that it is working correctly.
While I understand the need for good shell models in OOFEM, I can't spend so much time developing this, as I'm not payed to develop. The same goes for most others. Unless some of the developers have a need for a model, it is of course unlikely to be added.

If you can find a thorough description of the model you would like to have implemented, help set up input files for regression tests, then I can probably help you with the implementation. Otherwise, I'm afraid, rershell, tr_shell01, and quad1mindlinshell3d are your only options.

I did some tests, and the shell in planes XY and XZ works fine (see input and pic inside attached ZIP).

The model with the shells in YZ did not, no errors are reported when launching, except some warnings like this:

Warning: (zznodalrecoverymodel.C:194)
In ZZNodalRecoveryModeloofem::ZZNodalRecoveryModel::recoverValues:
some values of some dofmanagers undetermined

I digged into the code but I cannot still figure out why it happens.