Addition of a shared filter infrastructure #522
Conversation
This commit adds derived types, function pointers, and a filter list within a core type. These are added to enable support for a filter list within a core.
douglasjacobsen
force-pushed
the
framework/filter_infrastructure
branch
2 times, most recently
from
bbd2273
to
1df7626
Compare
|
@mgduda, @akturner, @matthewhoffman: This PR adds the filter infrastructure. I only added support for the test core in this PR, but I have a branch that also adds it to the SW core. The reason I point you to the branch that uses it within the SW core, is you can actually see what it does with time stepping. @mgduda: Let me know if the build system stuff is sufficient based on our discussion yesterday. To describe it, I allow a core to specify USE_FILTERS as 'true' or 'false'. If it's 'true' then filters are build and linked, if they are not being used by the core. This allows a core to easily skip over building of filters, though it complicates the build system a bit. Additionally, I've pulled out the parsing tool to extract filter information into it's own separate tool. |
|
@douglasjacobsen , is this the appropriate link for the design doc? |
|
@matthewhoffman Yes, thanks for linking it. |
douglasjacobsen
force-pushed
the
framework/filter_infrastructure
branch
from
1df7626
to
0a50560
Compare
This commit adds the mpas_filter_list module, which defines functions for creating, manipulating, using, and destroying a mpas_filter_list_type list.
This commit adds a new tool within the context of registry parsing to
extract filter information from an existing registry file. It can be
used to generate filter_function.inc, which can be used to define the
filter's for a core.
It parses filter and filter_list blocks from a registry file, with an
example as follows:
<filters>
<filter name="test1" module_name="mpas_test_filter1"/>
<filter name="test2" module_name="mpas_test_filter2"/>
<filter name="test3" module_name="mpas_test_filter1"/>
</filters>
<filters>
<filter name="test4" module_name="mpas_test_filter2"/>
<filter name="test5" module_name="mpas_test_filter1"/>
<filter name="test6" module_name="mpas_test_filter2"/>
</filters>
<filter_list name="group1">
<filter name="test4"/>
<filter name="test3"/>
<filter name="test1"/>
</filter_list>
<filter_list name="group2">
<filter name="test5"/>
<filter name="test2"/>
<filter name="test6"/>
</filter_list>
This commit adds filters to the build system in a shared src/filters directory. Additionally, this commit adds a driver which may be used to act on lists of filters. It is provided to allow cores to utilize shared functionality of a driver, without writing their own custom driver, but is not required to use filters. This commit also adds an example filter as mpas_filter_test_compute_interval. This filter can be used to test that the compute interval portion of the driver works correctly.
This commit adds filter setup / creation to the MPAS driver, to allow cores that include filters to have them setup automatically.
This commit adds support to the test core for filters. Additionally, it adds two filters to the test core that test the compute interval of filters.
douglasjacobsen
force-pushed
the
framework/filter_infrastructure
branch
from
0a50560
to
46eb809
Compare
|
@mgduda and @matthewhoffman I've pushed updates that make the build system easier to use (and hopefully more extensible). Let me know if you have any comments / concerns. |
|
With ifort 15.0.1, I'm getting the following build error for the test core: It seems that adding |
|
PR closed for now, but an issue has been opened to continue tracking this until active development resumes: #1476 |
This merge introduces an optional filter infrastructure which can be used to share kernels of code that can be used for a variety of purposes. It adds a new module mpas_filter_list which houses function pointers for each filter, and a new tool that can be used to extract filter information from a core's registry file.
Usage of filters within a core is optional, and a core can skip building the filters.
This merge comes with an example filter to test the compute interval functionality. Additionally, a driver is added to help cores that want to use filters share code to have some shared functionality of filters, such as compute intervals.