DIAMETER, THICKNESS conflict on PART line

[gforney]

Background: In a test case Topi was working on, the MATL THICKNESS was accidentally
set to 2 times the DIAMETER, which was also set on the PART line, and no error was
thrown.  Kevin and I discussed that we should throw a shutdown error if a DIAMETER
is set without giving a SPEC_ID on PART.

Unfortunately, from a quick glance, it does not seem so simple to me.  It looks like
the LP diameter is actually still set by DIAMETER, whereas the LPC density is defined
by a volume computed from half the THICKNESS.  So, someone who knows these routines,
please have a look and try to make this all consistent.  Thanks!

Original issue reported on code.google.com by randy.mcdermott on 2013-02-05 22:35:05

[gforney]

Along with this: We have RADIUS and THICKNESS on SURF. Should we have just one input
and have GEOMETRY define what it is?  Still not clear in the Guide or the source what
a Cartesian particle is.  Is THICKNESS the full thickness or the half? Should it be
dependent on the backside boundary condition (which doesn't seem like it works if it
is EXPOSED)?  Before starting to make changes we should decide on these and not risk
making changes that don't get us where we need to be.

Original issue reported on code.google.com by drjfloyd on 2013-02-06 14:18:01

[gforney]

Yes -- part of the confusion is that RADIUS and THICKNESS are not directly analogous.
THICKNESS refers to the thickness of layer N, whereas RADIUS refers to the outer radius
of a sphere or cylinder. I think a good place to start is to remove RADIUS from the
SURF line. I added INNER_RADIUS a few months ago, so regardless of geometry, one specifies
the THICKNESS(N) to mean the thickness of layer N. INNER_RADIUS is optional. The original
idea of RADIUS was just to specify a hot sphere as just a surface condition, with no
MATL_ID. But we determine THERMALLY_THICK using THICKNESS as the trigger. I think MATL_ID
is the better trigger.

I'll start with this change and then run the verification cases.

Original issue reported on code.google.com by mcgratta on 2013-02-06 15:23:00

[gforney]

I decided to keep RADIUS on the SURF line, except now RADIUS is just converted to THICKNESS(1)
upon input. But now, THICKNESS>0 no longer implies THERMALLY_THICK like it used to.
THERMALLY_THICK is tied to a positive value of SF%LAYER_DENSITY(1). There is no more
SF%RADIUS -- it is now SF%THICKNESS everywhere, the initial thickness or radius of
the solid.

I also removed SURFACE_DENSITY as an input. It was not used in the V&V and it was just
making things more confusing.

I ran the verification cases, checked them, and committed this change. I will continue
making other changes dealing with the THICKNESS or HALF_THICKNESS of a Cartesian plate.

Original issue reported on code.google.com by mcgratta on 2013-02-06 18:54:43

[gforney]

SVN 14632. Now a particle with a CARTESIAN (plate) geometry is assumed to like a sandwich.
THICKNESS is still used to indicate the THICKNESS of each layer that makes up the half-thickness
of the actual plate. We cannot rely on RADIUS or HALF_THICKNESS as inputs because they
do not indicate layer thicknesses. So if we want to construct a sandwich, HALF_THICKNESS
is not useful because we need to indicate the THICKNESS's of the bread and the salami.
Now, we specify the THICKNESS of one slice of bread and one slice of salami.

Original issue reported on code.google.com by mcgratta on 2013-02-06 22:33:47

[gforney]

Back to the original problem. Now, DIAMETER is set to -1 by default. The user must set
it or get an ERROR. If SURF_ID is specified, DIAMETER cannot be used. 

Original issue reported on code.google.com by mcgratta on 2013-02-12 21:52:05

[gforney]

Verified by firebot.

Original issue reported on code.google.com by mcgratta on 2013-02-26 14:16:39