search

grinsfem / grins

Multiphysics Finite Element package built on libMesh
http://grinsfem.github.io
Other
47 stars 39 forks source link

MASA linkage and Generalized Forcing Function Specification #260

Open vikramvgarg opened 9 years ago

vikramvgarg commented 9 years ago

We are ready to link MASA with the SA branch to test the turbulence model with manufactured solutions. Two questions arise:

1) Paul, is linking MASA to GRINS on your imminent todo list ? If not, Todd and I can take care of it tomorrow.

2) Does GRINS have the capability to incorporate a user specified forcing function ? All it should need is something along the lines of the user specified boundary conditions containers used in the turbulent channel and axisymmetric cyclinder tests. The user can create a Class whose operator specifies the forcing function (here via MASA) and then we pass a pointer to an object of this class to GRINS to compute the forcing function.

vikramvgarg commented 9 years ago

@nicholasmalaya @pbauman

More discussions with Nick have indicated that MASA linkage via the parsed/generalized forcing function would be easier to implement and use than creating a separate physics for the MASA linkage.

Since MASA only needs spatial and temporal variables from the library requesting the forcing function, we should not need the femfunction type capabilities that parsed_interior_function currently doesnt support (but will soon anyways).

Right now, I am creating a separate branch (masa_turbulence_source_hack) and simply hard coding the calls to MASA in parsed_source_term.C. Later on these hacks should become attaching function pointers in maps with their respective variables.

pbauman commented 9 years ago

More discussions with Nick have indicated that MASA linkage via the parsed/generalized forcing function would be easier to implement and use than creating a separate physics for the MASA linkage.

Huh? How was this conclusion reached? You could subclass the SourceTermBase class, but otherwise, MASA shouldn't touch the existing source terms since we have to make calls at points to get the values from MASA.

Since MASA only needs spatial and temporal variables from the library requesting the forcing function, we should not need the femfunction type capabilities that parsed_interior_function currently doesnt support (but will soon anyways).

This is correct.

Right now, I am creating a separate branch (masa_turbulence_source_hack) and simply hard coding the calls to MASA in parsed_source_term.C. Later on these hacks should become attaching function pointers in maps with their respective variables.

No. Create a new source term and hard code the calls to MASA.