Add Kloss to Input

[nfherrin]

EDIT: Note this vision is now outdated, after discussion with Ben we now want it to look like: https://github.com/UT-Computational-NE/FlowForge/issues/33

Current input format looks like

{
  "components": {
    "pipe": {
      "p1": {"R": 0.02949 , "L": 407, "n": 30, "theta":   150, "roughness": 1.075E-3}
    }
  },
  "controllers": {
    "bodyForce": {
      "power1": {"eq": "enthalpy", "value": "1.48*10**3*3/2.73211778128016E-03"},
      "power2": {"eq": "enthalpy", "value": "1.48*10**3*4*(z/100)**2/2.73211778128016E-03"},
      "power3": {"eq": "enthalpy", "value": "1.48*10**3*2*cos(z/pi)/2.73211778128016E-03"}
    }
  },
  "system": {
    "segment": {
      "order": [{"component" : "p1", "BodyForces" : ["power1","power2","power3"]}],
      "boundary_conditions": {
        "mass_momentum"  : {"inlet" : {"mdot"        : 25}, "outlet"   : {"pressure"    : 10132500}},
        "enthalpy"       : {"inlet" : {"temperature" : 823.15}, "outlet" : {"temperature" : 823.15}}
      },
      "fluid" : "FLiBe"
    }
  },
  "units": {
    "length": "m",
    "time"  : "s",
    "pressure": "pa",
    "massFlowRate": "kg/s",
    "power": "w",
    "temperature": "K"
  }
}

I would like to see Kloss input as

{
  "components": {
    "pipe": {
      "p1": {"R": 0.02949 , "L": 407, "n": 30, "theta":   150, "roughness": 1.075E-3}
    }
  },
  "controllers": {
    "bodyForce": {
      "power1": {"eq": "enthalpy", "value": "1.48*10**3*3/2.73211778128016E-03"},
      "power2": {"eq": "enthalpy", "value": "1.48*10**3*4*(z/100)**2/2.73211778128016E-03"},
      "power3": {"eq": "enthalpy", "value": "1.48*10**3*2*cos(z/pi)/2.73211778128016E-03"}
    },
    "surfaceForce": {
      "Kloss1": {"eq": "momentum", "value": "1.34"},
      "Kloss2": {"eq": "momentum", "value": "2.316"}
    }
  },
  "system": {
    "segment": {
      "order": [{"component" : "p1", "BodyForces" : ["power1","power2","power3"], "InletSurfaceForces": ["Kloss1"], "OutletSurfaceForces": ["Kloss2"]}],
      "boundary_conditions": {
        "mass_momentum"  : {"inlet" : {"mdot"        : 25}, "outlet"   : {"pressure"    : 10132500}},
        "enthalpy"       : {"inlet" : {"temperature" : 823.15}, "outlet" : {"temperature" : 823.15}}
      },
      "fluid" : "FLiBe"
    }
  },
  "units": {
    "length": "m",
    "time"  : "s",
    "pressure": "pa",
    "massFlowRate": "kg/s",
    "power": "w",
    "temperature": "K"
  }
}

[nfherrin]

@cgentry7 @bscollin See if you agree with my vision for Kloss terms in the input file. More or less matches the way we do BodyForces/WallFunctions.

[nfherrin]

Ok, so we actually do already have Kloss capabilities in SyTH, but it's wrong, it applies the Kloss term to every node in a component instead of just the first and/or last component surfaces. This is incorrect since it applies the Kloss term number of nodes times, so the physics changes as the number of nodes changes (since it will change how many times the Kloss is applied), but there is a workaround in the current input that should give a more or less correct answer.

Basically, you make a very small division in the component at the beginning and/or end of the component as new component(s) with a single node. The Kloss term is then applied to this new division instead of the component as a whole. This applies the Kloss term only once even as the number of nodes in the non-Kloss section of the component is changed. Since the division is finite, this is still incorrect, strictly speaking, since it uses node average properties instead of surface properties. However, the division can be chosen to be small enough that the fluid flow property change across the node is negligible, in which case the approximation should suffice.

A quick example, say a component of length 20 cm has a Kloss term of 1.4 at the entrance and 2.3 at the exit, then the workaround would go as this: A 0.001 cm slice at the entrance is made into a new single node component with a Kloss of 1.4 and an identically sized slice at the exit is made with a Kloss term of 2.3, while the central portion of the component now has a length of 19.998 cm and no longer has a Kloss term applied to it at all.

WARNING: When performing this workaround, note that any spatially dependent body forces/wall functions in the component should still be applied to the entry/exit splits as well as the central split, and the central and exit splits should include offsets for the $z$ directional flow variable. I.e. if the component in the previous example had a power of $12z^2-3z-4$, then that power would be the same for the entry split, but must be changed to $12(z+0.001)^2-3(z+0.001)-4$ for the central component and $12(z+19.999)^2-3(z+19.999)-4$ for the exit split. As the width of the splits goes to zero, this offset becomes less necessary, but strictly speaking should be done to maintain consistency in the physics.

I will also note that I am not sure what potential instability very thin slices may introduce in the solver... Perhaps none, in which case every split for this Kloss purpose should be set extremely small to make the physics more consistent, think 8 factors or so smaller than the length of the component, but it is likely that very small slices may add instability.

For more information on Kloss, see Section 1-8 of https://www.nrc.gov/docs/ML1220/ML12209A041.pdf and pages 356 to 358 of https://ansccny.wordpress.com/wp-content/uploads/2015/01/nuclear-1-thermal-hydraulic-fundamentals.pdf

[bscollin]

I still disagree that what is implemented is wrong, its just a different definition that makes sense in a wide range of applications and is consistent with the way its treated in many nuclear TH codes including RELAP and TRACE.

I'm assuming you are changing the input format based on our discussion this past Friday?

[nfherrin]

I'm not changing the input format yet (hence moving this to backlog) since you determined it was a low priority since we have the workaround. Do you have a reference for RELAP and TRACE treating it this way? I would be very surprised if they did, but I could be wrong.

Either way, the current way is definitely wrong without the workaround since the Kloss term gets applied more than once for more than one node, so the applied Kloss linearly increases as you increase the number of nodes.

[nfherrin]

Oh you meant changing the input format vision, not actually implementing it... Yes, here is the new vision once we implement it

{
  "components": {
    "pipe": {
      "p1": {"R": 0.02949 , "L": 407, "n": 30, "theta":   150, "roughness": 1.075E-3, "Klossinlet": 0.8, "Klossoutlet": 1.3, "Klossavg": 2.3}
    }
  },
  "controllers": {
    "bodyForce": {
      "power1": {"eq": "enthalpy", "value": "1.48*10**3*3/2.73211778128016E-03"},
      "power2": {"eq": "enthalpy", "value": "1.48*10**3*4*(z/100)**2/2.73211778128016E-03"},
      "power3": {"eq": "enthalpy", "value": "1.48*10**3*2*cos(z/pi)/2.73211778128016E-03"}
    }
  },
  "system": {
    "segment": {
      "order": [{"component" : "p1", "BodyForces" : ["power1","power2","power3"]}],
      "boundary_conditions": {
        "mass_momentum"  : {"inlet" : {"mdot"        : 25}, "outlet"   : {"pressure"    : 10132500}},
        "enthalpy"       : {"inlet" : {"temperature" : 823.15}, "outlet" : {"temperature" : 823.15}}
      },
      "fluid" : "FLiBe"
    }
  },
  "units": {
    "length": "m",
    "time"  : "s",
    "pressure": "pa",
    "massFlowRate": "kg/s",
    "power": "w",
    "temperature": "K"
  }
}

So as you can see, we now also want a component averaged Kloss term and want each component to own it's own Kloss terms. To enable orificing, the plan is to have a Kinlet addition for the hexcore that gets added on to the component Klosses and looks like this:

"hexmap":  [[1,2],
           [1,1,1],
           [1,1]],
"orificing":  [[1.3,2.8],
               [0.1,1.9,1.0],
               [2.91,3.1]],

[nfherrin]

As far as I can tell (at least according to their manual), TRACE applies irreversible form losses (Kloss terms) discretely at the surface/point they occur, which is what I have been advocating. See Pages 418 and 419 (and specifically equation 7-117) of: https://www.nrc.gov/docs/ML1200/ML120060218.pdf

I looked in the RELAP manual, but it was far less clear, some things looked like they were treating Kloss terms at discrete points, some things looked like they assumed flow properties didn't change in a component so they just applied it to the bulk component properties since those were the same as inlet/exit flow properties. In general, the RELAP manual just felt far less clear with the specifics of what it is doing. https://inldigitallibrary.inl.gov/sites/sti/sti/6899506.pdf