These are harmless. The biggest concern is that you might not see relevant warnings because you have been overwhelmed by meaningless warnings.

Also, you have an older OOFEM release, so many of these warnings have been adjusted already (though I'm sure there are still many more). I think it's very important to have no warnings as a goal, but unfortunately, most developers are not windows users, and we aren't aware that VS complains about these things.

A few of these we should turn off (and I'm doing that right now).

I mean the git repo.
We are very overdue for a 2.4 release as well.

Hi Mikael,

When I run in debug mode, I get only one error, which is the following. 

Error 156 error LNK1248: image size (8000008E) exceeds maximum allowable size (80000000)

Did you encounter the same.  But when I run in release mode I have no such problems.

Could this be fixed with some flags and where exactly please?  I am afraid this is too high a number?

Thank you

It is only happening with sm, because I unticked fm and tm.  I have not defined any options in cmake (such as suppress dev warnings, etc...).

Please see attached.

I am not sure why it is still oofem 2.3, I followed the exact instructions in the wiki page for the development version.

I downloaded git, and then used the following command:

 git clone http://www.oofem.org/git/oofem.git oofem.git 

I then got oofem.git directory loaded.  Is this not the right approach?  Or should I have also used the next command?

 git checkout -b develop origin/develop 

The sum of all *.obj files is 2.64 GB.  I always thought that 64 bit machines gives static memory of 4 GB but I may be wrong.  I have attached the list of object files for your ready reference please.

Thanks again.

Hi Mikael,

Yes with the git pull, I find that lsmastermatgrad.C has shot to 12.556 Mb.  Now I get 5 errors as you see in the attached please.

Thank you.

Yes it is due to deactivating FM but not TM (stokesflow connects the two problems in a multi-scale setting).
I will correct that, until then, just deactivate TM as well (or activate FM).

OK, so the error has been isolated to the classfactory. To be able to further isolate the error, could you check to see what happens with the filesize in "lsmastermatgrad.C" if you remove the line:

REGISTER_Material(LargeStrainMasterMaterial);

(I'd like to know if it's the templates that add to the object size or something else in the header).

Hmm, well, even if I found out exactly what part of classfactory was causing the large increase, I'm not sure what I would do about it even if i knew. This error is isolated to only MSVC debug builds, so it seems to belike a compiler performance bug. MSVC is hardly a good compiler in general in my experience.

There are a few things about the classfactory that might be the cause.
1. The templates.

template< typename T > Element *elemCreator(int n, Domain *d) { return new T(n, d); }
template< typename T > DofManager *dofmanCreator(int n, Domain *d) { return new T(n, d); }
template< typename T > GeneralBoundaryCondition *bcCreator(int n, Domain *d) { return new T(n, d); }
template< typename T > CrossSection *csCreator(int n, Domain *d) { return new T(n, d); }
template< typename T > Material *matCreator(int n, Domain *d) { return new T(n, d); }
template< typename T > EngngModel *engngCreator(int n, EngngModel *m) { return ( new T(n, m) ); }
template< typename T > Function *funcCreator(int n, Domain *d) { return new T(n, d); }
template< typename T > NonlocalBarrier *nlbCreator(int n, Domain *d) { return new T(n, d); }
template< typename T > ExportModule *exportCreator(int n, EngngModel *e) { return ( new T(n, e) ); }
template< typename T > SparseNonLinearSystemNM *nonlinCreator(Domain *d, EngngModel *m) { return ( new T(d, m) ); }
template< typename T > InitModule *initCreator(int n, EngngModel *e) { return ( new T(n, e) ); }
template< typename T > TopologyDescription *topologyCreator(Domain *d) { return new T(d); }

template< typename T > Dof *dofCreator(DofIDItem dofid, DofManager *dman) { return new T(dman, dofid); }
template< typename T > SparseMtrx *sparseMtrxCreator() { return new T(); }
template< typename T > SparseLinearSystemNM *sparseLinSolCreator(Domain *d, EngngModel *m) { return new T(d, m); }
template< typename T > ErrorEstimator *errEstCreator(int n, Domain *d) { return new T(n, d); }

template< typename T > LoadBalancer *loadBalancerCreator(Domain *d) { return new T(d); }
template< typename T > LoadBalancerMonitor *loadMonitorCreator(EngngModel *e) { return new T(e); }

// XFEM stuff
template< typename T > XfemManager *xManCreator(Domain *d) { return new T(d); }
template< typename T > EnrichmentItem *enrichItemCreator(int n, XfemManager *x, Domain *d) { return new T(n, x, d); }
template< typename T > EnrichmentFunction *enrichFuncCreator(int n, Domain *d) { return new T(n, d); }
template< typename T > EnrichmentDomain *enrichmentDomainCreator() { return new T(); }
template< typename T > BasicGeometry *geometryCreator() { return new T(); }
template< typename T > EnrichmentFront *enrichFrontCreator() { return new T(); }
template< typename T > PropagationLaw *propagationLawCreator() { return new T(); }


template< typename T > FailureCriteria *failureCriteriaCreator(int n, FractureManager *x) { return new T(n, x); }
template< typename T > FailureCriteriaStatus *failureCriteriaCreator(int n, FailureCriteria *x) { return new T(n, x); }

template< typename T > ContactManager *contactManCreator(Domain *d) { return new T(d); }
template< typename T > ContactDefinition *contactDefCreator(ContactManager *cMan) { return new T(cMan); }

2. The large amount of forward declarations.

class Domain;
class EngngModel;
class Element;
class DofManager;
class GeneralBoundaryCondition;
class CrossSection;
class Material;
class Function;
class NonlocalBarrier;
class ExportModule;
class SparseNonLinearSystemNM;
class InitModule;
class TopologyDescription;
class Dof;
class SparseMtrx;
class SparseLinearSystemNM;
class ErrorEstimator;
class InitialCondition;
class Patch;
class NodalRecoveryModel;
class SparseGeneralEigenValueSystemNM;
class IntegrationRule;
class MaterialMappingAlgorithm;
class MesherInterface;
class LoadBalancerMonitor;
class LoadBalancer;
class XfemManager;
class EnrichmentItem;
class EnrichmentFunction;
class EnrichmentDomain;
class BasicGeometry;
class EnrichmentFront;
class PropagationLaw;

class FractureManager;
class FailureCriteriaStatus;
class FailureCriteria;

class ContactManager;
class ContactDefinition;

3. The classfactory class itself.
It contains 29 std::map instance variables, but I don't see how that would make it into the object file when the classfactory isn't even used.

4. The header files that classfactory.h brings.

#include "oofemcfg.h"
#include "sparsemtrxtype.h"
#include "errorestimatortype.h"
#include "doftype.h"
#include "linsystsolvertype.h"
//#include "patch.h" // for PatchType
#include "nodalrecoverymodel.h" // for NodalRecoveryModelType
#include "integrationrule.h" // for IntegrationRuleType
#include "geneigvalsolvertype.h"
#include "materialmappingalgorithmtype.h"
#include "meshpackagetype.h"
#include "dofiditem.h"

#include <map>
#include <string>
#include <cstring>

I'm really just guessing at this point.

You could help me out by testing if doing any of these (and remove the #include "classfactory.h") makes up the difference in the file size.
(You would probably need to combine 1 and 2 to test 1.)
I'm betting it's 1 or 3 that's the cause.

You should be able to build without a shared library (I don't know if the same limitations applies to executeable binaries.
Setting
USE_SHARED=OFF
when using CMake will deactivate the DLL.
Of course, this means it can't be used with Python, and has some other downsides. I avoid suggesting this, but I don't know what part of classfactory.h is causing the sharp increase (as it only seems to happen with MSVC)-

Well, you have only declared some variables, but you never write any values to any of them.
When it comes to material status it's done in a few stages:

1. When the stress is evaluated (for some guess in the Newton-iterations) then the material model makes sure to store whatever state it needs for later in the material status. Typically the plastic strain. This is stored in a "temp" value, as we do not know if this is the final Newton-iteration.

2. When convergence (in the FE analysis) is obtained, the "updateYourself" function is called, and the material status should take care to overload whatever temporary status is stores into a equilibrated state. It typically looks like

this->plasticStrain =  this->tempPlasticStrain;

so that the temp values can safely be overwritten during the newton-iterations, while preserving the old equilibrated values.

3. When the tangent is requested, or some export module is used, then the material uses whatever it needs from the material status. "printOutput" is done after "updateYourself" for each time step.

Some things are cached as temporary variables, but are never stored as equilibrated values. This is typically if they are only needed to compute the tangent.
There is a rather minimal tutorial model, aptly named "tutorialmaterial.C", which is a minimal (but nontrivial) model which illustrates all of these concepts.

A few comments on C++. Inheritance we use mostly for extending common base classes.
If I make a new class that extends the base class, I overload whatever methods I'd like to change, and, in many cases, call the base class method

void
IsotropicDamageMaterialStatus :: printOutputAt(FILE *file, TimeStep *tStep)
{
    StructuralMaterialStatus :: printOutputAt(file, tStep); // This call the super-class
     // Here I can print additional things that i want, that is only applicable to my class.
}

You could do the same in MazarsMaterial. For debugging purposes, you are of course free to hack around in the code in whatever way you want, but in order to accept any additions, I'd probably like to see "gt" "gc" "alpha_t" and "alpha_c" added to MazarsMaterialStatus instead of it's super-super-class "IsotropicDamageMaterialStatus"
(if gt, gc, alpha_t, and alpha_c are sensible to add for all isotropic damage materials, then please adding them to the base class is of course fine).

Then the simplest is to declare the variables under "public:" in the headerfile, and remember to set write to them when the new values are obtained, e.g.

    status->alpha_c = ....