Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

setup_interface_count tests fail on multiple processors #9422

Closed
roystgnr opened this issue Jun 29, 2017 · 0 comments
Closed

setup_interface_count tests fail on multiple processors #9422

roystgnr opened this issue Jun 29, 2017 · 0 comments
Labels
C: Framework P: normal A defect affecting operation with a low possibility of significantly affects. T: defect An anomaly, which is anything that deviates from expectations.

Comments

@roystgnr
Copy link
Contributor

Description of the enhancement or error report

The userobjects/setup_interface_count.* tests all fail on moderate processor counts, when the subdomain setup count fails to match the gold standard count.

Rationale for the enhancement or information for reproducing the error

./run_tests -p 3 --re setup_interface_count
triggers all three failures for me.

Identified impact

(i.e. Internal object changes, limited interface changes, public API change, or a list of specific applications impacted)

These tests appear to have been designed to run only in serial. Unless I'm misunderstanding subdomainSetup(), expecting a count of its calls to remain constant in parallel would be nonsense - that method only gets used when an iterator over an element range passes from one subdomain to another, and that may happen less frequently or not at all when a mesh is partitioned between multiple processors, giving each processor ownership of fewer elements and potentially fewer subdomains.

I'm just going to force these tests to run with one processor.

roystgnr added a commit to roystgnr/moose that referenced this issue Jun 29, 2017
If we want to run these in parallel, we'll need to modify the object
to make it stop counting subdomainSetup counts, which we don't expect
to be consistent from partitioning to partitioning.

This fixes idaholab#9422 for me.
@permcody permcody added C: Framework P: normal A defect affecting operation with a low possibility of significantly affects. T: defect An anomaly, which is anything that deviates from expectations. labels Jul 31, 2017
jarons pushed a commit to jarons/moose that referenced this issue Oct 5, 2017
If we want to run these in parallel, we'll need to modify the object
to make it stop counting subdomainSetup counts, which we don't expect
to be consistent from partitioning to partitioning.

This fixes idaholab#9422 for me.
liuusu pushed a commit to liuusu/moose that referenced this issue Nov 13, 2017
If we want to run these in parallel, we'll need to modify the object
to make it stop counting subdomainSetup counts, which we don't expect
to be consistent from partitioning to partitioning.

This fixes idaholab#9422 for me.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: Framework P: normal A defect affecting operation with a low possibility of significantly affects. T: defect An anomaly, which is anything that deviates from expectations.
Projects
None yet
Development

No branches or pull requests

2 participants