We will need to implement contol where user will need to set direction and speed of wind. The following contol may be a good start:

See article on CodeProject: http://www.codeproject.com/KB/selection/angle_custom_control.aspx

Today Edward asked if I'm interested to meet Dr. Mikhail Bolgov, Head of the Surface Water Modelling Department, Water Problems Institute from Russian Academy of Science who was visiting Deltares.

They participate in some research project where they would like to use SOBEK to simulate River Volga:

Modules planned to be used there are:

• Sobek 1D flow for Volga river and tributaries
• Sobek 2D flow for the floodplains

They curently started with model discretization and already entered all cross-section for Volga river. Nearest weeks they will receive DEM of the area and will start working with 2D model. Questions which were arised are:

• How to create model easilly using available DEM data (unclear in which file format they will get it, AutoCAD / ArcGIS)?

• How to automate SOBEK 1D / 2D model with external model or in other words how output of the SOBEK model can be easilly converted into some third-party ASCII file format. They need it in order to couple SOBEK with their own ground-water models and with some US models (like MODFLOW).

The project is interesting since we don't have many clients in Russia yet and Volga is a big river crossing many cities so there will be many other clients interested to use it if project will succeed.

Edward Melger can provide more information about the project.

Attendees: Onno van Logchem, Alex Koster

To find out wat users expect from a new UI for Sobek two colleagues working at Deltares were interviewed this thursday. The experiences derived from interviews like these will be used to implement functionality that will satisfy most users (80/20 rule).

Missing functionality in the current Sobek version

Overview of conveyance for the whole network.
Cross section editor like in Hec Ras or Mike 11 (is planned in delftshell development)
Documentation for entry level user.
Inspection of waterbalance per node from within user interface.

Discussion of DelftShell UI

Possibility to work with several windows open is appreciated. Where possible user should be able to operate Sobek using the keyboard. Treenavigation, opening of views and running models should be possible from the keyboard. Editing input should also be done using the keyboard.
Viewing input and output at the same time (having more than one window open at a time) is very much appreciated.

Requirements

Output should still be accessible even if input has been modified.
Viewing input and output at the same time should be possible
Reimplement Case Analysis Tool
Facilitate working with many combinations of strategies and scenarios
Change properties of multiple objects in the map at once (ModelEdit)

Usage of Sobek

Calculations are usually in the order of 10 minutes. Calculation time varies between 10 seconds and 10 days.
Calculations may be performed for different combinations of Strategies and Scenarios. In current Sobek this means that the user needs to generate several cases using almost the same input.
Analyzing differences between input and output of cases is performed using Case Analysis Tool. Working with Case Analysis Tool has some drawbacks so sometimes people use their own tools.
To perform calculations for many combinations of strategies and scenarios a tool developed by Klaas Jan van Heeringen is used.
When error messages are generated by the flow module it is difficult to find out what should be done to fix the error. SobekCheck provides some validation of the input but in some cases this is not sufficient.

The terminology in DelftShell does not conform to the terminology people are used to.

Scenario : water related issues caused by climatic conditions (external source)
Strategy : man made measure to deal with water related issues
Model : schematization with x-sections, hydraulic structures, properties and boundary conditions
Case : combination of scenario and strategy

Hoi Onno,
 
Hier bij wat punten die mij opvielen tijdens het interviewen:
 
Termen:

    * strategie versus schematisatie
    * scenario versus randvoorwaarden
    * model is een schematiesatie met profielen, kunstwerken en eigensachappen 
      en randvoorwaarden
    * case = +/- strategie en scenario samen 

Algemene opmerkingen:

    * Rekentijd wordt geaccepteerd ('s avonds opstarten, de volgende dag 
      resultaat bekijken)
    * Output en input naast elkaar kunnen zetten (ivm traceren van fouten)
    * Loskoppelen van tijdsafhankelijke data in netter (laterale debiet)
    * Knopen in een schematiesatie zijn vaak gekoppeld aan modules (bijv. RR en CF).
      iwm overzicht dis/enablen als een module geselecteerd is
    * Werken via 2 assen: bij strategie-as en een scenario-as
    * Twee schermen van Netter naast elkaar kunnen zetten als je bijv in 2 lagen 
      bezig ben, of twee schematisaties (cases) aan het bewerken ben.
    * Input en output van verschiilende case beter met elkaar kunnen vergelijken
    * Ideaal zou zijn als je 4 case kunt klaarzetten en laten uitrekenen in 1 job.
    * Overzicht van alle Crossectie op een rij zou mooi zijn.
    * Het selecteren van een stukje schematisatie (ipv 1 knoop) met een overzicht 
      van eigenschappen die daar bij horen.
    * Selectie op type knoop en een overzicht van de eigenschappen
    * Foutmeldingen zijn niet altijd duidelijk

Opmerkingen schematisatie/netter:

    * ID's van knopen kunnen fixeren, zodat je toch knopen (input/ouput gegevens) 
      van twee verschillen schematisaties met elkaar kan vergelijken
    * Reduceren van het aantal klikken is wenselijk. Meeste klikken worden veroorzaakt
      door:  het maken van knopen + eigenschappen in Netter, het switchen van layers in
      Netter. (Gebruik van toetsen -- bv pijltjes toetsen -- zou helpen)
    * Suggestie om met pijltjes stroomopwaards/afwaards door de schematisatie te kunnen
      navigeren werd positief ontvangen

Tip:

    * CrossSection HEC wordt als goed ervaren

 
Okido, dat was het z'n een beetje,
 
 
Met een vriendelijke groet,
 
Alex Koster

The teamcity visual studio plugin allows you to test your local sources before committing them to svn. You can install the teamcity plugin by following this link. When your logged in you need to select My Settings and Tools.Here you can download it.

Before you can install the teamcity plugin you need to close visual studio.

When your solution is loaded you can login to teamcity by accessing the Teamcity menu inside visual studio.

Next you can choose to run a personal build

you select the project(s) in your solution you want to build. In the righthand screen you select the type of build/test you want to perform on the buildserver. In the lowerrighthandcorner of the screen you can check if you want to commit your sources if the test/build is successfull.

Happy coding
Onno

Thanks to Paul and Souhad we now have a Configurable menubar, toolbar system for menus and toolbars. This means that plugins can add their own menu items and toolbar buttons to the gui.

Current activation logic

The plugin remains responsible to add its own toolwindows to the view. For example the Projectexplorer plugin adds the project treeview in the ProjectExplorerPluginGui.Activate method:

        public void Activate()
        {
                 ..            
            //add project treeview as a toolwindowview.
            gui.ToolWindowViews.Add(projectTreeView, ViewLocation.Left, "Project Explorer", null);
                 ..
        }

Currently menus and toolbars from the plugin are added using the following method:

     IMainWindow.AddPluginGuiCommands(IPlugin plugin, IPluginGui pluginGui)

Currently this implies that menu's and toolbars will only be added to the MainWindow of your application. This method may have to be moved later on when we want to enable more flexibility to adding context menus to other parts of the gui.
The AddPluginGuiCommands method reads an xml config file belonging to the plugin. This solution seems to work although it looks a bit ugly. I guess this kind of functionality does not belong in a view.

Suggestions for Activation and Deactivation of Plugin

Plugin and PluginGui both implement activate and deactivate methods. Deactivation of plugin functionality is not implemented. A plugin should be responsible for cleaning up memory by disposing of objects created in the Activate method of either the pluginGUI or plugin.

I looked at the activation deactivation in Visual Studio. Visual studio expects the plugin to clean up its mess. This does not work satisfactory: a plugin like MZTools removes its menu (as you would expect) but plugins like AnkSVN and Resharper do not. The VS program needs to be restarted in order for the changes to menus and toolbars to take place. Therefore allowing for plugins to manage this does not seem a good solution.

Therefore I would like to suggest the following Activate/Deactivate scenario: Rebuild menus and toolbars by querying all plugins for menuitems and toolbar items for plugins with PluginGui.IsActive == true. (currently implemented in DelftShell.InitializeMenusAndToolbars)

In addition the logic for querying Viewproviders and modelproviders should be extended with knowledge about active status of plugins.

See presentation in attachment related to selection of a map control for DelftShell.

The final choice is SharpMap v0.9 for now and v2.0 in a longer term, including all related libraries such as:

• GeoAPI.NET - OGC compliant interfaces
• NetTopologySuite - implementation SFS Geometries defined in GeoAPI
• NPack - math
• Proj.NET - implementation of the OGC coortinate reference systems

Also ArcGIS implementation will be created somewhere in the future.

It looks like it has sufficient functionality to implement various schematization editors and visualization of results on a map.

The architecture taskforce held a meeting (2008-4-15) on the progress of NetCDF as the default output format for Delft3D and SOBEK. The presentation is attached.

Issues discussed (aside from topics mentioned in the presentation):

• Importance of adaptation en extension of the CF standard for output.
• Implementation challenges
• phasing out old tools and libraries (What is the end of life cycle for old file formats?)
• backward compatibility (Will we make sure all old files can be read and written?)
• programming language for conversion tools (Shall we use matlab or another dynamic language to implement the converters?)
• Planning

Agreed was that:
In the next few months we will work on creating converters to import and export cf/netcdf files from and to our current output files. (april - july)
In the 2nd half of this year we will work to change our output formats from his/nefis to netcdf.

Relevant links:
CF standard
CF standard names
NetCDF
Unstruc example requires access to delft3d/sobek repository
NetCDF sources with VS2005 solution requires access to delft3d/sobek repository

What should you be able to do with the plugins? Seeing some people working with DelftShell, I saw them looking for at least the following information:

• Is my plugin loaded?
• How do I start my plugin?

So let's first make list of plugins which are available and provide information whether they are loaded (activated) or not and allow users to activate or deactivate them .

As a design I'll take the firefox plugin window which I fiend very user friendly.

Not nice

Nice!

Network (Graph) File Formats
This is an example of a graph stored in a netcdf file. Source http://anusf.anu.edu.au/Vizlab/drishti/DrishtiHelp.pdf Data would be stored on edges or, coords or vertices. I'm not sure if I like it yet... It's a bit hard to search for because graph often means chart.

netcdf pt80 {
dimensions:
nvertices = 11 ;
coords = 3 ;
nedges = 3 ;
connections = 2 ;
variables:
float vertex_centers(nvertices, coords) ;
float vertex_radius(nvertices) ;
float vertex_volume(nvertices) ;
int edge_neighbours(nedges, connections) ;
float edge_radius(nedges) ;
float edge_net_length(nedges) ;
// global attributes:
:gridsize = 80, 80, 80 ;
data:
vertex_centers =
4.829041, 76.55481, 16.07257,
7.333344, 78.66669, 53.83331,
11.83334, 64.66669, 23.66669,
12.66666, 67.66663, 19,
13.5, 68.5, 27,
14.5, 79, 1,
23.76926, 78.15387, 0.2307739,
26.7973, 48.77142, 46.80756,
38, 44, 42,
39.40677, 66.16608, 61.58075,
51.37497, 60.37494, 43.25 ;
vertex_radius = 4.472136, 2.236068, 2.44949, 2.236068, 2.44949, 1.732051,
1.414214, 9.899495, 4.898979, 4.690415, 1.414214 ;
vertex_volume = 619.9999, 6, 6, 3, 2, 2, 13, 21150, 1, 3788, 8 ;
edge_neighbours =
1, 3,
7, 9,
8, 10 ;
edge_radius = 0, 3.605551, 0 ;
edge_net_length = 4.368e-005, 4.368e-005, 4.368e-005 ;
}

I ran into trouble with the buildserver the last two days. Suddenly a lot of tests were failing that were running ok on my computer. Today I found out what the problem was:
I tried reusing the TestModel and TestDataItem by referencing to another testproject from DelftShell.Plugins.ProjectExplorer.Tests. Because I referenced the other testproject its assembly got copied next to my testassembly. That's when a lot of strange things started to happen:

suddenly the testcount increased to 400 (previously it had been 285)
I got an error "DragDrop Registration did not Succeed" with showed a dialog on the buildserver causing the testproject to take forever

Today I made a seperate assembly to contain TestDataItem and TestModel. This assembly is now referenced by my test and the original test. The testcount dropped to 285 and no errors are occuring.