First, this would just be the default behavior. If a material model overloads the functions, there wouldn't really be a way to determine wether or not it stored full or reduced vectors. However, i still insist that the interface, setIPValue + getIPValue, should always just return the full vector, as the common denominator.
The elastic models would do this.

But in general, just because the we're solving for something less than full 3D (plane stress, plane strain, 1d) doesn't mean we always can get away with storing the internal variables in the equally reduced state. So it might not even be an option (as most material models doesn't even support plane stress right now).

Your comment on memory consumption is not at all correct;
Even in the extreme case of plane stress, and in a model that can reduce all the internal variables, you still wouldn't get to twice the memory consumption. The overhead from other internal variables, e.g. pointers, sizes, so, a quick estimate for the possible worst case scenario:
One GaussPoint in plane stress, containing one material status for an elastic material, will take up (meassured in sizeof(doubles)):
12 + statusDict = 19 + IntegrationPointStatus = 20 + StructuralMaterialStatus
A FloatArray takes up 3 + size of the array, so we end up with total size
44 + 4*length_of_array
So, for the reduced plane stress, you'd use 56*sizeof(double) for each GaussPoint, and for the full form you'd use 68*sizeof(double), so the memory consumption for a GaussPoint increases by a factor ~1.2 times more. That's a memory consumption I'd be willing to pay for the simplified logic, even for elastic models.

Storing them inside StressVector and StrainVector classes you still need to convert manually and do all that logic everywhere inside the material routines, or overload the access functions "at(...)", which will kill the performance they inherit from FloatArray (can't use any of them BLAS functions anymore, can't inline).

Before I say anything more, I need to point out that if the material models overload giveRealStressVector_*** they can do whatever they want internally. Returning full vectors in giveIPValue doesn't mean you actually store full vectors.

As for the memory consumption, I disagree. Correctness is paramount, so making it as easy for material models as possible should be prioritized. A 20% theoretical worst possible case scenario, probably 10% in more realistic extreme cases, and perhaps ~1% in common cases.

For example, RCM2Material, one of the materials which supposedly supports PlaneStress. It takes the reduces strain vector and expands it, filling it up with zeros. Fine for plane strain, but it's incorrect for PlaneStress.
Or maybe how PlasticMaterial calls "giveStressDependentPartOfStrainVector" for the reduce strain, is that really correct for both PlaneStress and PlaneStrain?
I really think these two models are broken here, as direct result of trying to work with reduced components. Supporting especially plane stress directly in arbitrary material models is very very hard to get right, just storing the same reduced components for all vectors is not correct at all.

-------------------------------------------

But none of that actually matters for these default implementations.
I didn't add full form of vectors as an additional discussion point. I simply can't do a default implementation of giveRealStressVector_Planestress/PlaneStrain/1d without the 3d version storing the full vectors since it would be calling the 3D function (i.e. it must run giveRealStressVector_3d as if it was called directly). It certainly wouldn't work to just zero out component 3, 7, 8 or the strain, just like the stress and expect correct results.
Should the internal damage/plasticity-variable be zeroed in the same components as the strain? Most likely not, so reducing any components requires detailed knowledge about the material models.
Can't make any of those assumptions on internal variables in the default implementations (since they would always be wrong).
Even specialized implementations for specific material models, it would be hard to keep track of what components you can reduce. So hard it's not worth it, rather you risk breaking stuff.

Then you are making assumptions about the material model. The default implementations should work for arbitrary models.

With anything but linear isotropic elasticity "eps_33 = -nu/(1-nu)(eps_11 + eps_22)" is not true. It would be like throwing away the previous FE solution and start iterating the next time-step from a linear elastic response. Awful convergence speed.

Luckily, no material models work like that. We always store the old converged values of internal variables + the temporary variables (which, when convergence is reached, replaces the old values). Material models will continue from the old, converged values of stress, strain, and other internal variables.
So if you modify the converged values, trying to reduce and restore them with estimates, you will break the material routine and just get garbage results.

One could do; delta_eps_33 = -nu/(1-nu)(delta_eps_11 + delta_eps_22), with the initial guess: eps_33_temp = eps_33_old_converged + delta_eps_33  (if "nu" is defined for the material model).
But we can never throw away the converged result, because when we call "MaterialStatus::updateYourself" it must be there .

Throwing away any temp values means recalculating them at the converged state again.. which is computationally expensive (this is the reason why we store the temp values in the first place).

Recomputing anything is, of course, an unacceptable solution.
This discussion is no different saying, "why store the temp stress in normal strain controlled analysis, clearly we can recompute the stress afterwards?"
We could, but we definitely aren't going to. For plane stress, we start dropping part of the strain and another part of the stress, but in the end it's the same thing. Just with mixed control and a lot more convoluted.

The function "computeOutOfPlaneStrain" would not something simple to implement, and one would no longer have the main advantage of all this, i.e: Implement 3D version, get PlaneStrain-, PlaneStress-, and 1D-support automatically.

As a prerequisite for implementing this default behavior in all the material models, it turns out is it necessary to modify how giveIPValue works.

Disclaimer: This has nothing to do with whether or not a reduced vector is stored in the material status. ( though it would be much much easier to implement this if it did)

It turns out that we must return the full vectors in the "giveIPValue" function. This is a good idea anyway, because we then no longer need the function "giveIntVarCompFullIndx" either (and giveIPValSize is almost redundant), but most importantly, it would allow us to fix a very serious bug:
Currently, when we export with e.g. VTKXML we get a zero value for the out-of-plane components for the *strain* in plane-stress simulations. The same applies to plastic strains etc. The strain component might not produce any work, but it is vitally important to output correctly anyway.
So, having giveIPValue return the full vectors is a must for more reasons than these default implementations.
It also turns out that all the code that uses giveIPValue also becomes simpler when it can just assume the full vectors (which is always a plus).

I'm working my way through it right now and there are a lot of inconsistencies in the giveIPValue+friends functions.
Vectors and tensors and sizes are used widly inconsistently, even within a material model (in ways that can't possible have worked with VTKXML export). I'm trying to correct as much as possible as I go through.
I leave @todo comments as I go where material models should fill in correct values when they expand their reduced vectors.

As I can't read up on the theory for every such material, so I'm just padding the vectors out with zeros (as before), but other developers should fix it (if they possess the theory knowledge for the specific material model). I'll be fixing the linear elastic materials at least.

There is a lot of code, and things weren't really always correct to begin with, so there is bound to be a bug or two left.

After some more investigation i see that we should do the same thing for all the ****Layer and fiber material modes, since they are also only combinations of stress/strain control.
I will (after my vacation) add default implementations for these modes as well.

However, with the actual integrated quantaties; 3dBeam, 2dPlate etc. these belong n the crosssection, since, of course, they use cross-section data.

This makes it easier to ensure that when you use, say, a fiberedcross-section, you actually get the fibers. Currently, if you used a 3dbeam, you would get the fibers added, and if you used 2dbeam, you would get it without fibers (no warning, no errors). This is very misleading. I'd rather have it print an error message, so that you either 1. Implement the lacking features, 2. Change the cross-section you use to just a simplecrosssection.