ECP 1: Establish time-to-solution for ABL about nalu

[mbarone81]

Adding to the activities list:
5. Implement Coriolis term
6. Implement user-defined initial condition for specified virtual potential temperature profile
7. Assess overall boundary condition approach for ABL simulations relative to prior art and any required improvements.

[spdomin]

@mbarone81 I just thoroughly read your modifications to the theory manual. They look great - many thanks. If you can change u^* to u^{\tau} to be consistent with the other usage of wall friction velocity, that would be great. Looking forward to your above activities..

[mbarone81]

Working on #5, Coriolis term

[spdomin]

I am starting on the saving of the data to an "inflow plane" to be used in a subsequent simulation.

Ideally, we could simply output the data at a surface, however, we may not have that functionality in STK_io. As a first step, I can create the input_output Realm (just like in TOS) and output data to that plane. Then, we could read that data within a stand-alone simulation. The later will always require an input_output transfer, however, the former (ideally) should allow output to the surface of the first mesh.

[mbarone81]

Sounds good -- the general capability would be to apply the field to any boundary surface (or plane). This could be accomplished by allowing for multiple planes. One can imagine, however, a use case where the inflow wind field is the same, but comes from a different direction of the compass for each wind plant simulation. In that case the position of the boundary planes for sampling may be different for each of these simulations and we would not want to rerun the ABL simulation for each one.

[spdomin]

@skennon10, does open-source Percept have the ability to read in a mesh (with blocks and surfaces) and export a chosen surface to a shell element?

[skennon10]

There is some code to do this, but it isn't exposed as an option. See PerceptMesh::convertSurfacesToShells.

Would you like me to run this on one of your meshes?

-- Steve

Try it on the ABL mesh in the Rtest repos; concentrate on the "Front" surface.... Thanks.

---

From: Stefan P. Domino [email protected]
Sent: Wednesday, November 9, 2016 9:56 AM
To: NaluCFD/Nalu
Cc: Kennon, Stephen Ray; Mention
Subject: [EXTERNAL] Re: [NaluCFD/Nalu] ECP 1: Establish time-to-solution for ABL (#3)

@skennon10https://github.com/skennon10, does open-source Percept have the ability to read in a mesh (with blocks and surfaces) and export a chosen surface to a shell element?

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/3#issuecomment-259465199, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVasJGoIi5bGhKA4iAF_6o21ZDCZWfixks5q8fssgaJpZM4KROvP.

[spdomin]

@marchdf and @mbarone81, here is the interface to providing an inflow from a periodic ABL:

1. In the first ABL, either extract a surface to a shell or create a mesh to which output can be provided.

2. modify the ABL sim to include an XFER from the fluids simulation to the input/output realm. Note the need to populate the bc data:

  - name: xfer_fluid_io
    type: geometric
    realm_pair: [fluidRealm, ioRealm]
    mesh_part_pair: [Front, block_101]
    objective: input_output
    transfer_variables:
      - [velocity, velocity_bc]
      - [velocity, cont_velocity_bc]
      - [temperature, temperature_bc]

3. Run the simulation with output to the ioRealm. Make sure that output is provided in the ioRealm:

   output:
      output_data_base_name: io_abl_results.e
      output_frequency: 5
      output_node_set: no
      output_variables:
       - velocity_bc
       - cont_velocity_bc
       - temperature_bc

4. Launch a new non-periodic ABL with the desired data at the inflow with the following "external_data" XFER objective:

  - name: xfer_io_fluid
    type: geometric
    realm_pair: [ioRealm, fluidRealm]
    mesh_part_pair: [block_101, Front]
    objective: external_data
    transfer_variables:
      - [velocity_bc, velocity_bc]
      - [cont_velocity_bc, cont_velocity_bc]
      - [temperature_bc, temperature_bc]

5. modify the "Front" bc from a periodic to the inflow (note the new external data flag)

    - inflow_boundary_condition: bc_inflow_front
      target_name: Front
      open_user_data:
        velocity: [10.0,0,0]
        temperature: 300.0
        external_data: yes

I should have an Rtest in soon...

[mbarone81]

@spdomin This looks good, look forward to trying it out..

[spdomin]

@mbarone81, okay, I verified the correctness in a LES channel. All looks correct. I also modified the ablUnsteadyEdge input file to output to a shell inflow plane. Then, I added a new input file to use this data as the inflow BC for the subsequent run.

As noted, this domain is acting strangely in the inflow/open config. We may want to change the top and sides to a symmetry? Not sure..

Here is the SHA1 for the rest commit: commit 5236b19421ee92d2c1acd8642cf33799980eb29c

The only caveat that I can think of now is that the subsequent run must include all of the dofs from the first simulation. This can be relaxed by specifying which inflow field is expected to be supplied by an external field (see below). So, some kinks to work out, but the hard part is done.

Candidate interface... Velocity external, temperature not..

    - inflow_boundary_condition: bc_inflow_front
      target_name: Front
      open_user_data:
        temperature: 301.0
        external_data:
         - velocity: yes
         - temperature: no

I think now, you still need to add each dof with the proper inflow value which is used for the first IC.

[mbarone81]

Finished and pushed nodal Coriolis source term, and verified against Ekman spiral exact solution. Now working on #6 on the list, user-defined temperature profile. Open BC has been working well as a top BC in test cases for doubly-periodic lateral boundaries so far.

[spdomin]

Transition to Jira.