On Tue, 18 May 2010, David Fuentes wrote: > I've always wondered where are the libMesh regression tests stored?
poorly > Are they available to the public? Just the examples (which aren't yet proper regression tests since they're not automated enough and we still eyeball-check the results) and the unit tests (which are good but incomplete). Derek has a bunch of other regression tests running, but on non-open-source applications of INL's. PECOS has a few, but not currently public. > For verification benchmarks of my adjoint hessian, I am currently > > 1) comparing adjoint gradient against finite difference gradient > 2) comparing sensitivity gradient against adjoint gradient > 3) and finally comparing adjoint hessian calculations against > finite difference of the gradient to compute the hessian > > Are there any other verfication benchmarks are you currently finding > useful? Just benchmark and manufactured solution problems. Start with e.g. nonlinear convection-diffusion, add whatever forcing function turns out to be required to give a desired manufactured solution, and make sure that the sensitivities you get on that problem converge to the correct analytic sensitivity. Not quite as useful as it should be, though. We caught an error in one adjoint sensitivity term this way, only because we happened to be testing out goal-oriented refinement at the same time; on the uniform grids we'd tried for that problem the discretization error overwhelmed the implementation error. >> Not sure yet (which is part of the reason for that second "no"). For >> large systems with implicit solvers the best thing to do is to write >> and read (asynchronously) to disk. For smaller implicit systems we'd >> want to keep the whole thing in memory. We're not planning on any >> (efficient) support for explicit systems. > > What did you have in mind for this ? For smaller implicit systems, I > have my own (hacked) version of your TransientSystem Class where I created > a (class member) std::vector of NumericVectors to store the data. > Solving heat equation, I run out of memory pretty quick for larger > number of time steps. That's the start of what we'd want to do, but with two more additions: 1. the vector<NumericVector> would just be a buffer of size N. After something's been written to the buffer, you tell a separate thread to start writing it to disk. Before writing anything to the buffer, you make sure the I/O thread isn't N steps behind you and you wait for it if it is. 2. For adaptive transient problems there'd have to also be a vector<SomeMeshModificationStructure> buffer. I/O of the whole mesh is expensive, but just recording enough data to be able to undo the refinement/coarsening/repartitioning at each step should be feasable. --- Roy ------------------------------------------------------------------------------ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
