Hi All, On Tuesday 27 August 2013 07:12:15 Atgeirr Rasmussen wrote: > Den 26. aug. 2013 kl. 17:20 skrev Andreas Lauser: > > On Monday 26 August 2013 14:20:18 Atgeirr Rasmussen wrote: > >> Den 23. aug. 2013 kl. 12:06 skrev Andreas Lauser: > >> [...] > >> (for example, a Newton solver not converging is not an exceptional > >> thing). > >> > >> That's a thing I see quite differently. The reason is that there are > >> about a million things which could go wrong that make the newton solver > >> diverge. If any and all of this cases is protected by a classical > >> "if(error) return error;" guard, you take quite a performance hit (by > >> means of the guards themselfs and by means of missed optimization > >> opportunities). On the other hand, C++ exceptions do not negatively > >> impact performance (for details, see > >> http://stackoverflow.com/questions/13835817/are-exceptions-in-c-really-s > >> low ). > >> > >> Semantics first: a Newton solver failing to converge is something that > >> should be expected, and to a large extent any reasonable software must > >> handle the possibility. Therefore it is not exceptional, and the event > >> should not be hidden from the API. > > > > well, i think that it is exceptional in the sense that this only occurs > > once about every fifty million invocations of the assembler for the local > > jacobian of an element. (and each single invocation of the local jacobian > > would require quite a few ifs in the traditional method.) IMHO that's > > exactly the use case for C++ exceptions. > > For something that happens every 5e7 invocation, I can agree that exceptions > are fine. Maybe I picked a bad example, but in my experience one needs to > handle non-converging Newton iterations more often than that, but for the > systems you solve it may not be true.
non-convergence should be quite rare compared to convergence, though. I also agree that only throwing exceptions on the toplevel of the newton loop is a bad idea. The problem is that a problem may occur at any evaluation of the local residual (and these are a _lot_). > I certainly interpreted you that way, I must have misunderstood your > intentions. It really comes down to where the boundary between expected and > exceptional behaviour is drawn, and that certainly would depend on error > frequency etc. yeah, I now slowly start to understand that you thought that the exception is only thrown in the event that the maximum number of Newton iterations is reached. If this was the case, I would totally agree with you. > I do not argue in favour of traditional error-handling, only in favour of > reporting file, line and error to the terminal so the user can send a > semi-useful message to the developer. I agree, so this was also a misunderstanding :). > >> That is why the macro prints file > >> and line number. On the other hand, the receiving end is rarely > >> implemented > >> (other than, perhaps at a very high level), and would not be able to use > >> this information anyway. > > > > Why this is an argument against using exceptions (an exception object may > > also carry that information and it can be printed by the exception > > handler)… > This is not an argument against exceptions, which I am very much in favour > of. Although I do not want to require: > a. That exceptions carry this info (file, line). > b. That all programs must catch all exceptions, to print the info. > Far simpler then, to keep the existing use of a macro for the error (and > throwing). agreed, see above. > >> This might be true for opm-core and opm-porsol, but eWoms catches > >> 'NumericalException' and tries again with a smaller timestep. As you can > >> imagine, is a relatively common case. > >> > >> This may be a performance bomb, see above. Even if it turns out to not > >> be, > >> it is in my opinion abusing the exception concept, since it is an > >> unexceptional event. > > > > only if this would happen frequently, see above. > > I assumed it would -- if it does not, we do not really disagree much, I > think. yep :) > >> Finally, if you really want to use a specific > >> exception for this, it should be something like NewtonFailureMaxIter or > >> something like that. > > > > well, we can talk about the naming, but in my experience, most of these > > errors occur in the assembly stage because the newton method decided to > > use an intermediate value which is out-of-range for the material > > relations. IMO, throwing NewtonFailureMaxIter in this case would be quite > > a misnomer. Maybe something like 'MaterialError' or so… > > Yes, that does sound better, does it not? It certainly contributes to > understanding what went wrong better. yes. I will modify the hierarchy a bit. Would you mind if the specific exceptions were derived from 'NumericalProblem'? that way one still only has to catch 'NumericalProblem'. > >> Introducing a new exception hierarchy is of dubious value. I think that > >> once you has digested the appropriate usage of the standard range_error > >> vs. out_of_range_error vs. invalid_argument vs. length_error and so on > >> (quick quiz: what is appropriate for an index check in an array), you > >> will not feel the need to complicate any further. If one feels the need > >> for specialty exceptions that is fine, but they should be defined close > >> to where they are used and inherit logic_error or runtime_error. > >> > >> I agree that most of these exceptions should not be caught. But i think > >> there is some value in the class-name of the exception object itself. > >> Again, that's similar to the errno variable of libc. (what do you want to > >> do if this one gets set to ENOMEM?) > >> > >> I can agree to that. It should be specific then, not NumericalException. > > > > yeah, maybe something also like "MaterialError", "LinearSolverError", etc. > > The result would not be much different, though: the timestep would be > > reduced and the Newton method would be restarted. IME the main value for > > analyzing what went wrong the error message (which gets printed anyway)… > > Sure, the handling side may not change, just the throwing side. Although if > we never actually exploit the benefit of specific exceptions, I will > reiterate one of my initial points: just use std::exception. well, the only thing which we currently take advantage from is the property that 'NumericalProblem' is not a 'hard' error on the programmer's side vs. the rest are... cheers Andreas -- A programmer had a problem. He thought to himself, "I know, I'll solve it with threads!". has Now problems. two he -- Davidlohr Bueso
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Opm mailing list Opm@opm-project.org http://www.opm-project.org/mailman/listinfo/opm
