search

QMCPACK / miniqmc

QMCPACK miniapp: a simplified real space QMC code for algorithm development, performance portability testing, and computer science experiments
Other
26 stars 34 forks source link

Goals for next version of miniapp #241

Open prckent opened 5 years ago

prckent commented 5 years ago

Assuming we have learned all we need for the Exascale project from the current version of the miniapp, we need to ask whether we need to make a new version and what the goals should be before making changes that might need to be unwound or simply be effort that does not help ECP.

Requirements, suggestions can be put below. We'll have a discussion on the ECP project but this will be several weeks away due to existing commitments.

ye-luo commented 5 years ago

We wrote some goals initially, https://github.com/QMCPACK/miniqmc/blob/develop/goals.md#general-principles. I think miniQMC is never a separated project and it serves QMCPACK. If something is taken from QMCPACK, it needs to be studied by miniQMC. If some changes are agreed to be merged on miniQMC, it is meant to be propagate back to QMCPACK. It is much convenient to test new hardware and software with miniQMC than QMCPACK. This is a recurring need within and beyond ECP projects.

prckent commented 5 years ago

The question is not about the existence of the miniapp but what our goals for a v2 might be. Since QMCPACK mainline is going to be rearchitected, perhaps that needs to happen first. Or perhaps we need to try something (still) in the miniapp first. i.e. The assumption I wrote about might not be correct. The aim of this issue is to capture some requests. What we shouldn't do is keep updating the minapp without some broadly agreed on goals in mind.

lshulen commented 5 years ago

Something that I would be interested in exploring is the role / scope of refactoring in the miniapp. A lot of the challenges we face concern what happens when our experiments have diverged greatly from the initial mini app. One the one hand, I think this is a great strength of the miniapp idea that we can do these large experiments, but as we see, there has been much consternation figuring out what to do when these experiments are finished.

I don’t know the best way forward, but if we could figure out as smoother “governance” model to handle these larger architectural changes, it would help us with the process for the main application as well.

PDoakORNL commented 5 years ago

Refactoring implies that you are finding an optimal design through continued development and generalization of code based on the emergent requirements of the code base. If new specializations and design ideas are blocked from ever entering the code then refactoring is a pretty empty exercise, you're just doing incremental rewrites. If you never bother to look for generalizations until the entirety of a new implementation is done its also very difficult.

ye-luo commented 5 years ago
  1. miniQMC is designed to serve QMCPACK. miniQMC needs to reflect QMCPACK algorithms and implementations. v2 is missing #239 and #223 algorithms.
  2. New ideas needs to be exercised on separate branches. After sufficient discussion, demonstration and validation, good architectural change may get in miniQMC ahead of QMCPACK. Solid benefit and viability needs to be proven including a smooth transition path to guarantee that QMCPACK will be changed the same way and there is no divergence between QMCPACK and miniQMC eventually.
PDoakORNL commented 5 years ago

Goals are statements like the following:

We would like to use miniqmc to come to agreement on how to do the following in QMCPACK: a. Develop on a Single Source (rather than in execution or repo branches controlled and used by one developer) b. Fall back to CPU single walker evaluation easily. c. Support specialization for different algorithms and devices. d. Improve QMCPACK's design to simplify, clarify and lower the barrier to contributing.

I think you are saying with 1. and 2. of the previous comment:

  1. MiniQMC should be like QMCPACK in every significant detail and share the same architecture.

  2. We will continue to develop in separate branches until... the project leader declares a winner. And implying a third:

  3. 1 is always more important than 2.

  4. will raise costs for any idea that refactors or rethinks QMCPACK's design rather than primarily adding code to the imports from QMCPACK.

So if I'm not wrong about what @ye-luo the previous comment means I think these two sets of goals are incompatible. QMCPACK needs to fight its ball of mud design to achieve a.,b.,c.,d. but 1., 2., 3. favor ball of mud.