search

E3SM-Project / transport_se

Atmosphere transport mini app
1 stars 1 forks source link

create test case which matches ACME watercycle prototype #4

Closed mt5555 closed 9 years ago

mt5555 commented 9 years ago

Small test cases are good for debugging. For performance, we need a ne120 test case that matches the ACME watercycle proptotype (our best estimate of what ACME v1 will look like),

To match ACME, we need: for all test cases: rsplit = 3 (remap every 3 timesteps) limiter_option=8 (monotone limiter) use PPM vertical remap

Just for the ne120 performance test: set tracers to 50

mrnorman commented 9 years ago

I always test at ne8 for my quick tests since they run on just a few nodes in less than a minute per simulated day. For testing, since it's transport only that I use, I use limiter8 and limiter4 because they exercise different parts of the tracer code. I think we just need a set of tests that together exercise the portion of the code we are working with, and I think it can be an evolving list. For non-linear tests, we need a way to tracking growth in differences, so maybe one or two should turn on really frequent I/O to make sure that a given change is in line with, say, compiler flag changes.

-Matt

Matthew R. Norman Computational Climate Scientist Scientific Computing Group National Center for Computational Sciences Oak Ridge National Laboratory

From: Mark Taylor notifications@github.com Sent: Thursday, June 25, 2015 1:56 PM To: ACME-Climate/transport_se Subject: [transport_se] create test case which matches ACME watercycle prototype (#4)

Small test cases are good for debugging. For performance, we need a ne120 test case that matches the ACME watercycle proptotype (our best estimate of what ACME v1 will look like),

Reply to this email directly or view it on GitHubhttps://github.com/ACME-Climate/transport_se/issues/4.

mt5555 commented 9 years ago

One good thing about the DCMIP tests that David put in: we have an exact solution and we can compute errors. These have prescribed wind, so they are linear. And thus I think for verification, all we have to do in ensure the l2 and max errors have not changed, min/max violations have not changed, and mass is conserved.

mrnorman commented 9 years ago

I still think that limiter_optim_iter_full will introduce non-linearities even to linear flow, because the limiting itself is non-linear. But it's not too big a deal. Bugs usually show up clearly as long as you compare it to diffs with flag changes and alternate compilers.

-Matt

Matthew R. Norman Computational Climate Scientist Scientific Computing Group National Center for Computational Sciences Oak Ridge National Laboratory

From: Mark Taylor notifications@github.com Sent: Thursday, June 25, 2015 2:06 PM To: ACME-Climate/transport_se Cc: Norman, Matthew R. Subject: Re: [transport_se] create test case which matches ACME watercycle prototype (#4)

One good thing about the DCMIP tests that David put in: we have an exact solution and we can compute errors. These have prescribed wind, so they are linear. And thus I think for verification, all we have to do in ensure the l2 and max errors have not changed, min/max violations have not changed, and mass is conserved.

Reply to this email directly or view it on GitHubhttps://github.com/ACME-Climate/transport_se/issues/4#issuecomment-115347508.

mt5555 commented 9 years ago

limter=8 is actually linear in the sense that if you apply it to a tracer "q", or a tracer "a*q+b", it will preserve that linear relationship. It may be nonlinear in some other definitions though.

But either way, I'll conjecture that small changes in the limiter will grow linearly and not exponentially. Matt, you have the most experience with this - have you seen exponential growth for tracer only tests?

mrnorman commented 9 years ago

I think I have seen exponential error growth. I'm taking norms of relative absolute differences in tracer output for baroclinic flow with passive tracers. There are several fields in the ASP tracer definitions where the relative diff norms grow from 10^-16 to to 10^-8 in just 10 to 20 steps. I know the baroclinic dynamics are non-linear, but the tracers themselves should still be linear in those tests, right, since they're passive?

-Matt

Matthew R. Norman Computational Climate Scientist Scientific Computing Group National Center for Computational Sciences Oak Ridge National Laboratory

From: Mark Taylor notifications@github.com Sent: Thursday, June 25, 2015 2:19 PM To: ACME-Climate/transport_se Cc: Norman, Matthew R. Subject: Re: [transport_se] create test case which matches ACME watercycle prototype (#4)

limter=8 is actually linear in the sense that if you apply it to a tracer "q", or a tracer "a*q+b", it will preserve that linear relationship. It may be nonlinear in some other definitions though.

But either way, I'll conjecture that small changes in the limiter will grow linearly and not exponentially. Matt, you have the most experience with this - have you seen exponential growth for tracer only tests?

Reply to this email directly or view it on GitHubhttps://github.com/ACME-Climate/transport_se/issues/4#issuecomment-115352587.

mt5555 commented 9 years ago

The ne120 test I think is much to long for performance work - we need to shorten in to just run a few hours instead of 12 days.

Any objections to having people verify their changes with the ne8 and ne30 tests, and have a much shorter ne120 test for performance?

mt5555 commented 9 years ago

https://github.com/ACME-Climate/transport_se/commit/87046e624cc3d085694b8caade269ee61ee2a6c8