search

NREL / EnergyPlus

EnergyPlus™ is a whole building energy simulation program that engineers, architects, and researchers use to model both energy consumption and water use in buildings.
https://energyplus.net
Other
1.09k stars 382 forks source link

Material:InfraredTransparent issues #7384

Closed mjwitte closed 5 years ago

mjwitte commented 5 years ago

Issue overview

  1. Noticed this code in the setup for Material:InfraredTransparent in HeatBalanceManager::GetMaterialData: 
            if (MaterialNumProp >= 1) {
            Material(MaterNum).Resistance = MaterialProps(1);
            Material(MaterNum).ROnly = true;
        } else {
            Material(MaterNum).Resistance = 0.01;
        }

    It appears that the object at one time had more input fields, but currently, the object only has a name field. So MaterialNumProp will always be zero, and ROnly will not be set true.

Not sure what the implications of this may be. Will need to track down what happens with ROnly and see if this changes results for runs with an IRT material.

  1. Also, since the object has no other input fields, this if and following could be reduced to just the default assignments.

  2. "Surface Inside Face Net Surface Thermal Radiation Heat Gain Rate" does not balance. In InitInteriorRadExahange the area used in the radiant exchange calculations is doubled for IRT surfaces. Ultimately NetLWRadToSurf [W/m2] is calculated in CalcInteriorRadExchange using the 2xArea, but then this flux is applied to the surface heat balance on an equal basis with other perArea values. NetLWRadToSurf needs to be multiplied by 2 at the end of CalcInteriorRadExchange.

Details

Some additional details for this issue (if relevant):

Checklist

Add to this list or remove from it as applicable. This is a simple templated set of guidelines.

RKStrand commented 5 years ago

@mjwitte Any idea on the history or purpose of this input field? Is it to separate a zone into like an upper and lower area for stratification? The docs are not very detailed in either the IORef or EngRef. Also, in the IORef there is only one input--a name. In the code, there is the possibility of four additional numeric fields. These are not documented. So, are those fields "researcher only" fields that are undocumented or were used for testing? I will leave them there for now and fix the three items you mentioned above.

As for what happens with an ROnly material, it basically tells the CTF routines to treat it as such and there is a way that it handles that that is slightly different than if the material has density and specific heat. With very small R-values in materials that also have thermal mass, there is the possibility of some instability in the solution. My guess is that since the documents don't mention the other fields that no one knows about them and isn't messing around with them.

mjwitte commented 5 years ago

@RKStrand Well, we can't ask the original author anymore. The extra field processing should be removed to avoid confusion. Also, I tried doing a 2x on the netLWRad in my AirWall branch, and it went unstable, so not sure if #3 above is just a misunderstanding on my part of if the solution is trickier than it looks.

RKStrand commented 5 years ago

@mjwitte Ok, I'll remove the extra fields to avoid confusion and just set everything to the defaults. I'll also see if I can understand the logic behind the 2x and make a decision on what if anything should be done. My guess is that the whole thing is a bit touchy...

mjwitte commented 5 years ago

There's some discussion of the intent in the engineering reference under "Infrared Radiation Transfer Material". It's original purpose is somewhat questionable, but I'm planning to use the same method as one of the options for treating radiant exchange in the new Construction:AirBoundary object. Without the 2x it seems stable, but the reported IR exchange doesn't balance. Maybe it's just a reporting thing and we need to put the 2x on the output variable, but that's not clear to me yet. The 2xArea included in the view factors and in the ScriptF, I haven't gained enough understanding to know if that's already producing the correct intensity in W/m2 when the surface heat balance happens.

RKStrand commented 5 years ago

@mjwitte Ok, here is my take at why NetLWRadToSurf is multiplied by 2 and this appears not to be done in the heat balance. It's because this type of surface would be a "partition" and the heat balance equation factors this into its unique formulation of the equation for temperature at a particular surface. So, multiplying the value in the heat balance would be wrong because the equation form has already factored in the two sides facing the zone. The radiation exchange has to multiply by 2 because it is using the same equation for each surface. The inside surface heat balance has a variety of equations: one for inter-zone partitions, one for partitions (same temperature at both sides), etc. In other words, I think the current code is doing this correctly. So, multiplying the value by 2 in the heat balance would be incorrect and could lead to weird results. Does this make sense?

mjwitte commented 5 years ago

Does it make sense? Sort of, but not completely. These are used on interzone surfaces, so only one side of the surface is interacting with a given zone. Do you see a place in the code that uses the "partition" equation for IRT surfaces?

RKStrand commented 5 years ago

@mjwitte Hmmm...I was looking at one of the example files that used IRT and I see that I misread that file. Sorry--my mistake. Yes, you are correct it needs to be an interzone surface. Now, why it is including the area twice during InitInteriorRadExahange is a mystery to me. I don't see any logical reason to do this. Without any documentation and no access to the original author, all I can do is speculate. Is this a variation of a "fast" surface and the author is trying to account for the fact that there will be addition LW absorption on the opposite side that will conduct across quickly and thus need to be accounted for in the interior surface heat balance? There are "fast conduction" cases at the exterior surface heat balance. Perhaps this was a way of doing this without rewriting the inside heat balance. Or perhaps this is just all too sensitive and this was a way to stabilize things? Not really sure, but I'm not sure that trying to mess with this is a good idea. Seems like this was put in for a reason. I vote we leave the code as is with respect to item 3 above and not try to mess with something that doesn't seem like it is really getting used very often. What do you think?

mjwitte commented 5 years ago

The 2x area is explained in the engineering reference, with equations. See ""Infrared Radiation Transfer Material".

RKStrand commented 5 years ago

@mjwitte Wow--I'm really not firing on all cylinders today. Not sure how I missed that section. Ok, I think that I have a guess as to why it's doing the multiply by 2 in that one place and not anywhere else. I think it has to do with the fact that it is a weird case where it's not really there but it is. So, to satisfy the heat balances, it acts like a surface in the overall heat balances. However, when it tries to do a radiation balance, because it is not really there and what you are trying to accomplish is mimicking the radiation from the other zone which is really in fact the same space physically but articifically broken into two zones by the IRT. So, to try to include the radiation going on in the other space, it includes the side facing the actual zone because it has to and the other side facing the other zone to try to mimic the radiation going on in the other zone. The documentation says it's receiving radiation from both sides so maybe that is why it is multiplying this by 2. That's my thinking at the moment though I am not thoroughly convinced that it should be doing the 2x. Seems like maybe a fast way to do this that avoids having to try to do a radiation balance on two zones at the same time. Technically, you would combine all of the radiation exchange from both zones, but that gets messy given the assumption of a zone in EnergyPlus. I guess I lean towards leaving this as is. What do you think?

mjwitte commented 5 years ago

@RKStrand For the air boundary work, I will be adding an option to combine two or more zones for the radiation exchange, but I the plan also includes an IRT surface option for the air boundary. My big concern is that "Surface Inside Face Net Surface Thermal Radiation Heat Gain Rate" does not balance which leads me to think that the current 2x method is not conserving energy, but I haven't proven that yet. I'll work on a test case to check the energy balance.

RKStrand commented 5 years ago

@mjwitte Ok, yesterday I clearly wasn't thinking (might have had a few distractions). Sorry that this impacted the discussion here. I see what you are saying and I agree with you that something is not right here. I did a straight test with one of the example files and produced a net radiation imbalance as a result of the 2x not being carried through to NetLWRadToSurf. This isn't right. Now, when I eliminate the 2x multiplier in the Init routine, then I do get a balance of radiation. So, the question is do we eliminate the multiplier in the Init routine or modify NetLWRadToSurf at the end of the Calc routine? In reality, I'm not super convinced in the whole 2x multiplication in the Init--I was more grasping at straws trying to understand why it's there. Maybe it's there for a reason I don't comprehend yet. Not really sure. What do you think? I can implement either one.

RKStrand commented 5 years ago

@mjwitte Just checking back with you about the previous comment. Which do you think makes more sense for implementation: eliminating the 2x multiplier in the Init routine or modifying NetLWRadToSurf at the end of the Calc routine?

mjwitte commented 5 years ago

I don't know. That's for you to ponder :-)

RKStrand commented 5 years ago

@mjwitte Ok, as I don't have a solid explanation as to why one would multiply the IRT surface areas by 2, I am going to eliminate that. I have done some testing and it shows that the radiation does in fact balance when this change is made. Without any explanation to the contrary and despite that this was done purposely, I think this makes the most sense.

mjwitte commented 5 years ago

Closed via #7441