Attending: Sarah, Bryan, Rupert, Gerry, Antoinette, Sylvia, Marie-Pierre,Sophie, Mark E, Balaji, Frank

Actions:

·        Mark to email the list about the issue regarding the terminology for file and the number of them (file versus file instance). Files should have multiple variables underneath them.

·        Assign all wording change tickets to Charlotte. She can then reassign to Gerry, Rupert or Bryan as necessary as all can change wording on any of the pages.

·        Gerry and Antoinette to work on allowing questionnaire users to see what they’ve input in a nice format – rendered, printable version.

·        Mark E and Charlotte will work on setting up the first page ofquestionnaire with an “Example Modelling Group” group filled with dummy data toallow people to see what it’ll look like.

·        Bryan to create a ticket for big lists in coupling which need to be saveable and editable in pieces. Also to allow option of “none” for temporal regridding.

·        Eric and Marie-Pierre to create a ticket on expanding all possible couplings. Flag run time inputs inmind maps so none will come through to questionnaire.

·        Bryan  to create a new ticket to allow simulation copying.

·        Bryan  to think about the option of downloading a xml file and then upload it as a new simulation to edit.  

·        Eric – find out who’s going to be doing simulations and needs access to the questionnaire this year so we can engage with them as soon as possible. We’ll need a name for each institution. Email Karl for contacts.

·        Bryan will document critical path with keyword and report so we can see how things are going.

·        Sarah to sort a doodle poll for the next questionnaire telco.

Decisions:

·        End of November is the deadline for release.This gives us 3-4 days of software development, but more time than that for thecontent (help text etc). 

·        Definitions for the ticketpriorities are as follows:

o  blocker - broken

o  critical - will be done

o  major  - should be done

o  minor - could be done

o  trivial - might be done

o  issue – won’t require coding,needs to spawn into a ticket with other priorities when the issue is"resolved" by the group.

·        Runtime inputs can be allowed everywhere and people can put them where they make sense. The runtime input button will appear everywhere except at model level.

·        There will be a link from CMIP5 website to the running version of questionnaire.

·        When we get to the point of not trashing and burning the questionnaire versions, the underlying structure in the relational database can’t change. We can add new things but can’t make logical structural changes.

·        We may have to tell users to adjust their browser default font sizes to solve font size issues in the layout.

·        Decision was made to leave the capability in to allow input requirements that come from the mind maps, but remove the specifics.

·        Make a 15 minute video of someone going through questionnaire explaining it as we go. Also have a page by page video (possibly using Wink). We should encourage people to watch the video – maybe make the first time they log on to questionnaire they have to watch the video.

·        We’ll copy and backup the data in the questionnaire every day.

·        Users are allowed delete user added attributes if they’re in the wrong place but can’t move them and can’t delete a user-added components.

·        Some component attributes aren’t applicable to all components, so having an option as n/a to describe it is a good idea. Will need to pass the non-applicability “n/a” across to the CIM – should happen anyway. Validation will need a tweak.

·        Schedule for release – all blocker and critical tickets will be done. Then freeze all the vocabulary beyond changing their values. Everyone will then need to go through all the pages of the questionnaire to check all the values from the questionnaire.

·        Next version of questionnaire will be released early next week.

Issues:

·        Bryan is still corresponding with Karl re realm vocabulary being consistent.

·        We need to specify documentation about specific bits of the questionnaire in tickets (e.g. boundary conditions etc) as well as write the more general help documentation.

·        Issue of how things will behave with lots ofentries – we’ll probably need to change the user interface to deal with this later.

·        Next priorities – simulations output andcoupling – add import and export to xml to round-trip to dump contents out for updates.

Notes:

Agenda for telco – We need to determine what needs to happen before the questionnaire is released. The definition for the priorities need to be agreed and we want a clear definition and method for getting the questionnaire released.

Updated timescale after GO-ESSP:

            WGCM will mandate the questionnaire.

            Want data available as soon as it’s in the data node.

            Questionnaire needs to be released by end November

Some modelling groups need to do metadata on a per simulation basis.

Once we release questionnaire we need to be able to update it and keep what people have been putting in it.

End of November is the deadline for release. This gives us 3-4 days ofsoftware development, but more time than that for the content (help text etc).  Rule out changing anything in the structure at this time.

86 experiments – only 1 simulation per experiment (each simulation mayinclude multiple ensemble members) Machinery exists to copy and change simulations for ensemble members.

A parameter change is the same as a code modification in the questionnaire –need a better phrase for this?

Initial conditions and initialisation method – need single phrase todescribe this too.

Bryan will get the version he has up for people to test. 

Ticket 344 not Bryan’s problem – will be dealt with in validation.

Prognostic variables – captured in mind maps under key properties now.Doesn’t matter if they end up under attributes. Ticket 279 dropped back to being an issue.

Output variables are going to be mapped onto realms.

Ticket 284 – redundant conformances – people might need to enter conformances more than once, dropped in priority.

Time step now appears in key properties.

Proper documentation – help documents etc – blocker? Need to specify documentation about specific bits of the questionnaire in tickets (e.g.boundary conditions etc)

People need to be able to upload ancillary files. Only 1 variable per file uploaded. File is the wrong word. Won’t appear in drop down lists in newversion.

Worried that all of our testing has been with few entries – how things behave with lots of entries will be different – will probably need to change theuser interface to deal with this later.

Issue – terminology for file and the number of them (file vs file instance).Files should have multiple variables underneath them. Mark to email.

Semantic information in namelist will be asked somewhere else. Need clear distinction between ancillary files that are something named (boundarycondition) or are just extra information.

If you change email address at one component, do you expect it to propagate through the sub-components? Not so easy to do. Will manage users in another layer. Less of an issue when bundling is working.

Next version of questionnaire needs to have latest version of controlled vocabulary in it.

Questionnaire layout bugs (ticket 328) is a widespread css issue. Will be a lot ofwork to sort out.

Component xml output – where are we on simulation export? Been on hold until now – Rupert

Next priority – simulations output and coupling – add import and export to xml to round-trip to dump contents out for updates. Will dumping it capture all the internal states of the questionnaire? Scary- means version updates can’ttouch the underlying model. Relational databases – can extend but not change.

Tabs – tabs are keeping track of the last model and simulation you lookedat. Do we need other tabs for file, coupling, ensembles? No – all controlled by model and simulation. Tabs contain independent things.

Not in tickets:

·        Content appearing that shouldn’t be there–people need to specify where that’s happening in new version.

·        Files – can’t edit a file description. Fixed in latest version.

·        For any given boundary condition in model description – can fill it all out in model and information in 1 and 4 will be copied across, while 2 and 3 you have to put in manually.

·        Model inputs can be put in by the user, or can be brought in from the mind maps.

·        Should there be any input requirements that comefrom the mind maps? Decsision made to take the get_data bits out of the mind maps and then they won’t percolate through, though capability will still be there.

·        Can’t couple until you have something to couple to – need to define run time input to couple to. Coupling can be run time input from file, or from other component.

·        Option of “none” for temporal regridding

Next version has way of copying a model. Can’t copy a simulation at the moment. Day or two’s work to make it happen. Option to download xml file and then upload it as a new simulation to edit? Bryan to think about it.

Allowing copying of simulations – do we believe that people will make all the changes or will we end up with wrong simulation metadata?

Bundled mind maps not finished yet.

Engage with people using questionnaire as soon as possible. Mark E is one of those people. Eric – find out who’s going to be doing simulations and needs access to the questionnaire this year. Need name for each institution. Email Karl for contacts.