• Registered: 16-10-2010
  • Posts: 407

Topic: beam01 not working and windows compatibility

Hi all,
I'm trying to get to work beam01. I noticed that there was an error at line 92, IntArray is missing; it must be rewritten as:

beam->setField(IntArray{ 6 }, _IFT_Beam2d_dofstocondense);

I suppose that under linux this would not be a problem, since it has never been fixed before.

Anyway, I get another error when running:

Total number of solution steps     3
_______________________________________________________
Error: (C:\OOFEM_LMAT\oofem_cure\src\oofemlib\floatarray.C:555)
In oofem::FloatArray::assemble:
dimensions of 'fe' (3) and 'loc' (0) mismatch
_______________________________________________________
No backtrace available
Total 1 error(s) and 0 warning(s) reported
oofem exit code 1

this is the stack:

     oofem.dll!oofem::FloatArray::assemble(const oofem::FloatArray & fe, const oofem::IntArray & loc) Line 555    C++
     oofem.dll!oofem::EngngModel::assembleVectorFromBC(oofem::FloatArray & answer, oofem::TimeStep * tStep, const oofem::VectorAssembler & va, oofem::ValueModeType mode, const oofem::UnknownNumberingScheme & s, oofem::Domain * domain, oofem::FloatArray * eNorms) Line 1087    C++
     oofem.dll!oofem::EngngModel::assembleVector(oofem::FloatArray & answer, oofem::TimeStep * tStep, const oofem::VectorAssembler & va, oofem::ValueModeType mode, const oofem::UnknownNumberingScheme & s, oofem::Domain * domain, oofem::FloatArray * eNorms) Line 912    C++
     oofem.dll!oofem::LinearStatic::solveYourselfAt(oofem::TimeStep * tStep) Line 230    C++
     oofem.dll!oofem::EngngModel::solveYourself() Line 534    C++
     oofem.dll!oofem::LinearStatic::solveYourself() Line 182    C++
     beam01.exe!main(int argc, char * * argv) Line 202    C++

can you help on that?

Moreover, in order to keep the compatibility under windows:
- in heap.C (saying that “pow is ambiguous”), please change #include <math.h> in #include <mathfem.h> on line 4
- "uint” is a type not supported by VS, please replace with “unsigned int” in all the files ( geometrygenerator.C, quasicontinuum.C )

Giovanni

  • Registered: 25-06-2013
  • Posts: 241

Re: beam01 not working and windows compatibility

Hi, I pushed a fix for beam01 and changed uint to unsigned int; however, I don't understand the ambiguity of pow.

Martin

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: beam01 not working and windows compatibility

Hmm, all of heap.* and grid.* really is very very far from modern C++.
I really think modern code should: (1) never contain any new/delete, (2) no C-style casts, (3) no calloc/malloc (std::vector always), (3) always empty destructors, (4) use initialization lists, (5) no owning pointers, (6) avoiding loop index, (7) local definitions, (8) no macros, (9) no C headers.
This code is pretty much the opposite, which is quite worrying.

I'm not surprised at all if the C style math functions causes some ambiguity for MSVC. We should really only use ones in the std namespace from cmath.

  • Registered: 16-10-2010
  • Posts: 407

Re: beam01 not working and windows compatibility

Thanks Martin, beam01 is now correctly working.

Another important question: in C and python bindings, all the sample cannot deal with the results. I mean, there's no exaplanation on how to extract results and use them in the calling program (python or a C++ exe).

Is this possible? Are there proper methods to do this? If not, I'm wondering what is the purpose of having APIs to write the model and not to read and postprocess the results.
Thanks

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: beam01 not working and windows compatibility

You would basically ask the EngineeringModel-object for the Domain (which is almost certainly domain 1, as most/all solver just use 1 domain right now).
The MatlabExportModule::doOutputData could be a good reference for accessing the solution field.

Initialization is more difficult and more fragile than dumping the output. We have to sanitize input, do secondary initializations, like creating necessary dofs, computing transformations for slave dofs etc.
Output is easier, and you can just request the element, ask it what IP value it has.

Now, we *do* have the concepts of Fields, and we can create and pass out primary fields and internal variable fields. These would be the ideal interface to access the high level solutions from the analysis. My goal has been that all the export modules would  use as well (when possible).

6 Reply by johnnyontheweb (edited by johnnyontheweb 15-07-2017 16:02:04)

  • Registered: 16-10-2010
  • Posts: 407

Re: beam01 not working and windows compatibility

Another compilation issue under windows:
in classfactory.h, __attribute__((unused)) must be removed. What is this for?

EDIT:

The MatlabExportModule::doOutputData could be a good reference for accessing the solution field.

I'm having a look into that module, thanks for that hint. Another, hopefully last, question: can the output file be avoided to be written on disk and be kept in RAM only? IN other words, is there an istruction to tell OOFEM to NOT write the .out file?

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: beam01 not working and windows compatibility

Hi again (I'm still on vacation and can't answer often)

The attribute is a linux specific thing to turn off a false warning about an unused variable. You can remove it for now. I'll try to look at a nicer solution in a future (preferably one that wont require any evil macros).

Yes, it's fully possible to run OOFEM without writing (or reading) from disk. Im in the process of converting the old outputmanager to a normal export module, so that's it's optional. Until then there are hacks to prevent the *.out file that Erik implemented in order to prevent oofem from running out of file descriptors when running FE^2 simulations (i believe that the option was called "supressoutput" for the engng model line). This option will soon be deprecated, along with the "outputmanager" which will get replaced.
If you call the code from Python or from your own main function, you can also simply not call the "do output" methods, or give it a custom output stream (though this is somewhat unlikely).