Unclear behavior using lumped species

[gforney]

FDS Version: 6

I have some confusion about the distinction between lumped and primitive species. In
the User Manual, the sections for 'Primitive' and 'Lumped' species are clearly separate,
with almost no overlap in between. I am curious however what FDS actually does in the
case that a lumped species is defined with a primitive variable, such as CONDUCTIVITY_SOLID
on the same SPEC line.

I tried testing this in FDS6 and no errors or warnings specified the type of file to
be invalid. However, I am concerned that I have no way of knowing whether or not those
'Primitive' parameters are actually being applied to the lumped species, given that
the manual provides no examples that demonstrate this type of species definition.

Clarity would be appreciated. Thank you in advance.

Original issue reported on code.google.com by albrecht@thunderheadeng.com on 2013-11-13 22:54:25

[gforney]

The primitive vs. lumped distinction was designed for the gas phase.  Please send an
input file as an example of what is unclear.  Thanks.

Original issue reported on code.google.com by randy.mcdermott on 2013-11-14 13:34:32

[gforney]

The attached file is an example of what I am trying to ask. CONDUCTIVITY_SOLID was a
variable I chose at random. What I am trying to understand, is whether or not it is
appropriate or at all allowable to specify 'Primitive' variables such as

...CONDUCTIVITY=.1, VISCOSITY=.2, SPECIFIC_HEAT=.3, DIFFUSIVITY=.4/

...when defining a lumped species. I failed to find any example files where this type
of declaration is used, but there is nothing in the manual warning that it cannot be
done. Are the above stated variables thrown away? Or are they applied as one would
expect to SPEC 'Custom_lumped'? Sorry for the poor initial explanation.

Original issue reported on code.google.com by albrecht@thunderheadeng.com on 2013-11-14 15:06:33

---

• _Attachment: lumped_spec.fds_

[gforney]

If you look at the .out file you will see that these properties are not applied to your
custom lumped species.  But, I agree, it would be good to both spell this out in the
user guide and add a stop error message to the code.  Thanks for pointing this out.

Original issue reported on code.google.com by randy.mcdermott on 2013-11-14 15:15:27

[gforney]

Randy and Jason,
Is this perhaps something we want to allow and we aren't allowing?

Original issue reported on code.google.com by CraigWeinschenk on 2013-11-14 15:22:18

[gforney]

I don't think so.  I'd rather this be set on the primitive spec line.

Original issue reported on code.google.com by randy.mcdermott on 2013-11-14 16:33:07

[gforney]

I don't think we want to allow lumped aerosols or liquid drops. Evaporation or deposition
should be only a pure species.  However, we should allow the gas from liquid evaporation
to be used (I.e. sprinklers will need the primitive species for evaporation but we
still use the lumped for combustion products)

Original issue reported on code.google.com by drjfloyd on 2013-11-14 17:40:59

[gforney]

Jason,

I started to add a check just for DIFFUSIVITY, VISCOSITY, CONDUCTIVITY, SPECIFIC_HEAT...
but when I got into it, it looks like there are many properties that are permissible
to change on the SPEC line for primitive species, and to be thorough we should address
each one.  At a glance it was not clear to me what the cleanest way to do this would
be, if not basically repeating SET_SPEC_DEFAULT.  Could you please take the lead on
making this change? Thanks.

R

Original issue reported on code.google.com by randy.mcdermott on 2013-11-14 20:00:05

[gforney]

I think the cleanest way to do this is have a block like:

IF (SPEC_ID(2)/='null') THEN
   check for inputs
ENDIF

I think we want people to be able to give new inputs for a copy of a primitive species
(for example multiple soot species but with different diameters) but multi-component
lumped species should just be the weighted average of all the primitive species. 

Original issue reported on code.google.com by drjfloyd on 2013-11-15 19:01:21

• Labels added: Application-FDS

[gforney]

I guess this is what Craig was arguing for.  I do see the utility in that.  But seems
like the most general way to do it is how Craig was suggesting, which was to allow
the user to overwrite the properties for a lumped species, no?

Original issue reported on code.google.com by randy.mcdermott on 2013-11-15 19:17:57

[gforney]

But is this something we want?  The concept behind the lumped is a more efficient way
to track a group of primitive species.  If we are redefining properties, shouldn't
we just define a new primitive species?

In a related note if a user defines a species as AEROSOL and then uses that species
in a multi-component (number SPEC_ID > 2) lumped species, should we stop on an error,
give a warning, or just have a line in the .OUT saying DEPOSITING or NON-DEPOSITING
in the species summary?  My inclination is the last plus a note in the user's guide.

Original issue reported on code.google.com by drjfloyd on 2013-11-15 19:25:35

[gforney]

Well, my original inclination was that we do not want it.  But I was thinking of how
you "copy" a primitive species with all its properties and it seemed to me you would
have to create a lumped species with a new name and give it a volume fraction of 1
with the primitive species being copied.  So, how do you envision the copying of prim
spec to look?  Like this?

&SPEC ID='METHANE 2', SPEC_ID='METHANE', LUMPED_COMPONENT_ONLY=.TRUE./

I am fine with whatever you want to do with AEROSOL.  I don't know enough about how
the deposition and evap stuff is working right now.

Original issue reported on code.google.com by randy.mcdermott on 2013-11-15 19:40:39

[gforney]

for copies of primitive - is the example in the user's guide unclear?  

Page 118 Two Gas Species with the Same Properties

or was I misunderstanding your question?

Original issue reported on code.google.com by drjfloyd on 2013-11-15 19:52:15

[gforney]

In the example in the User Guide, both 'CO 1' and 'CO 2' are lumped species with volume
fraction 1 of CO.  So these components show up in the Z vector, each is tracked.  I
thought we were talking about creating new primitive species Y with basically the same
properties, but maybe one property changed.  Then these primitive species could be
used within a lumped species with various weights.

Original issue reported on code.google.com by randy.mcdermott on 2013-11-15 20:01:05

[gforney]

You can do:

&SPEC ID='CARBON MONOXIDE',CONDUCTIVITY=10.,LUMPED_COMPONENT=.TRUE./

but you then wouldn't be able to have CARBON MONOXIDE with the normal properties.

OK, I'll look to see a clean way to override the primitive variable averaging for one
or more quantities of a lumped species.

Original issue reported on code.google.com by drjfloyd on 2013-11-15 20:06:37

[gforney]

I added the keyword PRIMITIVE to SPEC.  Default is .FALSE.

This would create a lumped species with all the properties of OXYGEN except cp
&SPEC ID='O2',SPEC_ID='OXYGEN',SPECIFIC_HEAT=2/

This would create a primitive species with all the properties of OXYGEN except cp
&SPEC ID='O2',SPEC_ID='OXYGEN',PRIMITIVE=.TRUE.,SPECIFIC_HEAT=2/
which you could then use in a lumped species definition.

Original issue reported on code.google.com by drjfloyd on 2014-06-17 16:52:45

[gforney]

hmm... on second thought, does it make sense that we would ever not want to just make
it a primitive species in this case?  A primitive species without LUMPED_SPECIES_ONLY
is always also a lumped species.  Maybe the correct approach should be if there is
only one specified SPEC_ID to always make it primitive?

Also realized my changes won't work in the case where SPEC_ID isn't built-in.  Need
to adjust the logic there.

Original issue reported on code.google.com by drjfloyd on 2014-06-17 17:02:53

[gforney]

There may not be a practical way to deal with a non-built in species as no way to tell
what inputs a user has given on the namelist vs. which are the default.  The user's
guide should be made clear on this.

Original issue reported on code.google.com by drjfloyd on 2014-06-17 17:14:33

[gforney]

OK got rid of PRIMITIVE and instead any duplicate predefined species becomes a primitive
species.  Updated the user's guide with additional explanation.

Original issue reported on code.google.com by drjfloyd on 2014-06-17 17:48:37

[gforney]

broke the outputs for species copies.  This needs some more work.

Original issue reported on code.google.com by drjfloyd on 2014-06-18 12:33:39

[gforney]

After various trial and error and thinking about how this would be used I decided the
keyword PRIMITIVE is the correct way to go.  I will update the User's Guide to reflect
this.

Original issue reported on code.google.com by drjfloyd on 2014-06-23 14:07:06

[gforney]

(No text was entered with this change)

Original issue reported on code.google.com by drjfloyd on 2014-08-11 14:18:12