On Wednesday, September 18, 2019 at 11:28:45 PM UTC-4, Wolfgang Bangerth wrote: > > > Doug, > > It does not greatly surprise me that it doesn't compile -- what isn't > tested > generally doesn't work. >
Makes sense. We'd of course be very happy to accept any patches to make things work. The > general approach to making stuff work is to *always* use hp::FEValues > objects > to evaluate solution fields. You might want to look at some of the > functions > in VectorTools that can either take a ::DoFHandler or hp::DoFHandler to > see > how they work and how the code is written to accommodate both kinds of DoF > handler classes. > I think I should be able to get away with always constructing a high-order geometric grid for now, but I I'm guessing that it's not going to be the only hurdle I encounter with hp. Seems like the same philosophy applies to collections e.g. I should *always* use a FECollection of FESystem of FiniteElement since that seems to encompass all possibilities. If I do end up needing those features, should I open an issue and ask to get it assigned to myself? And then refer to that issue for pull requests? A good strategy to implement these kinds of changes is to split things up > into > a number of incremental changes. Each of these individually doesn't get > you to > the end point, but fixes one roadblock at a time. I find it much easier to > work this way (using many individual pull requests to get to the final > goal) > than to try and write one monumentally large one, principally because each > step individually can be sent through the test suite. (There are 23 tests > right now that use this class, so it's reasonably well tested.) If no > tests > break, then it can't have been so wrong, and one can move on to the next > problem. I've definitely implemented things many times that took a > sequence of > 10 pull requests, each making incremental progress. Writing several new > tests > in the process is definitely also helpful. I'd suggest you try that > approach. Thank you for the tip. I did not realise that pull requests could be used for "partial" features (as long as they don't break the code). This is my first large(ish) project where other students contribute to the code, and I'm trying to mimic the forking workflow of open-source projects. Will definitely recommend them to do pull requests more often to reduce merge conflicts. -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/f59549dd-144c-4687-8cda-3adb141b526f%40googlegroups.com.
