-
Notifications
You must be signed in to change notification settings - Fork 0
FeedbackYPW
I think that the primary task of the committee for the near future should focus on a better and more consistent benchmarking, and integration of various code development into the trunk. Coordination of sciences could be done quite loosely through the regular CABLE community meetings. Therefore I suggest that two working groups: one is the technical working group and other is to organise regular CABLE meetings (so it is CABLE meeting coordinator role, not CABLE science role) and inform the CABLE community timely the various studies using CABLE or developing CABLE. I disagree with having two separate groups on CABLE offline and online. The principle for CABLE development should be: if some that is great science but does not work globally in ACCESS, that work should remain in the branch, not the trunk. Having too many switches just makes the codes difficult to understand and use for the CABLE community. Strategy and resourcing is an important issue. But I feel that this should be done at higher level. Science codes should be managed by the technical committee.
Should the coordinator be one of the working group leads or not?
I think that there should be two coordinators: one on technical committee and other on CABLE community science meetings.
Should the coordinator be part of the strategy working group?
Yes.
Does the coordinator need to be the person who leads communication activities e.g. the email list and meetings?
Not necessarily in order to share the work load a bit for the CABLE science community coordinator, but yes for the technical committee, because they have to make decisions from time to time.
Have we got enough people who are willing to put time into being part of a working group?
Yes only for two groups.
What process would we use to appoint people to working groups and, as leads, to the committee?
Whoever does the job provides the service to the community, for which we are all grateful. So I think that you just appoint whoever is willing to doing the job.
Would it become the responsibility of each working group lead to find their own working group members?
We should only have the core members for the technical committee, not the science working group. I also think that benchmarking should be part of the technical committee.
Should we ask for annual involvement rather than an open-ended commitment?
Not sure what you mean here.
Is this too large a departure from current practice?
We need to learn from the past experiences. Benchmarking has been lagging behind. Rules for integrating codes into trunk have not been applied consistently. We have not been very efficient in integrating various code upgrades into the trunk.
Benchmarking test, particularly including global offline and online simulations should be the most critical part of the work flow. It is unrealistic to do this for every ticket raised, but must be carried when a substantial codes are integrated to the trunk. Again this is the reason why I recommend benchmarking should be integral part of the technical working group.
Another point about work flow is documentation. All model developers, including myself are guilty parties on this, and we need to do better. Without adequate documentation, users will struggle. One form to improve this without adding too much tasks to the developers is to provide regular technical updates on the user guide.
Back to agenda/minutes