OpenMPI error in FunctionDT

[agiorla]

Description of the enhancement or error report

Creating a FunctionDT TimeStepper with time_t and time_dt inputs of different sizes causes an unexpected MPI communication error such as

application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0
[unset]: write_line error; fd=-1 buf=:cmd=abort exitcode=1
:
system msg for write_line failure : Bad file descriptor

There should be a test in the constructor to check that time_t and time_dt have the same size (or where-ever that bugs occurs, I am not sure)

Rationale for the enhancement or information for reproducing the error

This would provide the user a clearer (and less scary) explanation of why his/her input file causes an error, and what to modify in its input file.

Identified impact

Changes to FunctionDT TimeStepper or one of its attributes (I am not sure where it happens).

[permcody]

Have you run your input file through a debugger? Should be pretty easy to narrow this down. Also run in serial when you do that you and should get a line number. At the very a least an input file that we can use to reproduce would be helpful.

[agiorla]

See below an input file that fails, at least on my workstation. I tried with different --n-threads and it gives me the same error.

Don't get me wrong, I know that there is an error in the input file and that Moose should stop. It would be just nicer if the error were caught by Moose error system instead of MPI ;)

`[Mesh]
type = GeneratedMesh
dim = 2
xmin = -1
xmax = 1
ymin = -1
ymax = 1
nx = 2
ny = 2
elem_type = QUAD9
[]

[Functions]
[./exact_fn]
type = ParsedFunction
value = tt(xx+yy)
[../]

[./forcing_fn]
type = ParsedFunction
value = 2t(xx+yy)-4tt
[../]
[]

[Variables]
[./u]
family = LAGRANGE
order = SECOND
[../]
[]

[ICs]
[./u_var]
type = FunctionIC
variable = u
function = exact_fn
[../]
[]

[Kernels]
[./td]
type = TimeDerivative
variable = u
[../]

[./diff]
type = Diffusion
variable = u
[../]

[./ffn]
type = UserForcingFunction
variable = u
function = forcing_fn
[../]
[]

[BCs]
[./all]
type = FunctionDirichletBC
variable = u
boundary = 'left right top bottom'
function = exact_fn
[../]
[]

[Executioner]
type = Transient

start_time = 0
end_time = 20
[./TimeStepper]
type = FunctionDT
time_t = '0 4 8 12'
time_dt = '1 2 4'
interpolate = false
[../]
[]

[Outputs]
exodus = true
[]`

[permcody]

Well maybe... For one time checks and simple input validation errors, yes you should get a sensible error message. However, we also tend to use assertions if a check needs to happen in a hot spot to avoid the expensive of branching. We remove those assertions in the optimized binary for optimum speed. So we have a mix. We always recommend that developers check their inputs in debug mode first to see if at least we are catching a problem with an assert. It sounds like this case probably should be looked at. Thanks for the input file.

[friedmud]

I'm not sure why this is contentious. This class is definitely missing an up-front input validation step. Right in the constructor it should check that time_t and time_dt have the same length and mooseError() if they don't. I'm honestly really surprised that it doesn't... This is a real issue.

…

On Fri, Jul 14, 2017 at 10:35 AM Cody Permann ***@***.***> wrote: Well maybe... For one time checks and simple input validation errors, yes you should get a sensible error message. However, we also tend to use assertions if a check needs to happen in a hot spot to avoid the expensive of branching. We remove those assertions in the optimized binary for optimum speed. So we have a mix. We always recommend that developers check their inputs in debug mode first to see if at least we are catching a problem with an assert. It sounds like this case probably should be looked at. Thanks for the input file. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9498 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA1JMTXYmgdbpY0P0-bQ05zWONy2nBEfks5sN3zFgaJpZM4OYPpP> .

[friedmud]

To be clear: this has nothing to do with MPI. You'll just end up getting a segfault if they don't have the same size. When that happens you may get MPI errors spewed to your screen because a process died unexpectedly... but it has nothing to do with MPI itself.

…

On Fri, Jul 14, 2017 at 12:14 PM Derek Gaston ***@***.***> wrote: I'm not sure why this is contentious. This class is definitely missing an up-front input validation step. Right in the constructor it should check that time_t and time_dt have the same length and mooseError() if they don't. I'm honestly really surprised that it doesn't... This is a real issue. On Fri, Jul 14, 2017 at 10:35 AM Cody Permann ***@***.***> wrote: > Well maybe... For one time checks and simple input validation errors, yes > you should get a sensible error message. However, we also tend to use > assertions if a check needs to happen in a hot spot to avoid the expensive > of branching. We remove those assertions in the optimized binary for > optimum speed. So we have a mix. We always recommend that developers check > their inputs in debug mode first to see if at least we are catching a > problem with an assert. It sounds like this case probably should be looked > at. Thanks for the input file. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#9498 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AA1JMTXYmgdbpY0P0-bQ05zWONy2nBEfks5sN3zFgaJpZM4OYPpP> > . >