Whats Happening With Geomodeller. Discussion Forum
peterg
the last 3 years (with varying levels of success) and whilst the
consortium has made progress there are still several key issues that
have not been resolved (in my opinion). These issues are holding
Geomodeller back from reaching its full potential as an innovative 3D
geological modelling package that can be used reliably on a variety of
different geological situations.
Some of you, I know, may feel the same frustrations with the
development speed and implementation of new features. Perhaps it is
time to consider discussing these issues amongst the users in an open
forum and get some feedback and have one voice on what the important
issues are so we can feed these back to Geomodeller and get some
action.
I'll happily start the ball rolling with some of the main issues I
feel need to be immeadiately addressed:
1. DYKES, yes I'll say it again dykes... We have asked for
improvements to building dykes to implemented for over 2 years now and
still nothing has happened. Basically this is one of Geomodellers main
weakness's. Geomodellers ability to build geologically meaningful
dykes or thin intrusive structures and maintain their continuity
across a project without having to resort to building hundreds of
crossections is very poor. Can we have a timetable and suggestions for
implementing the improved building of thin intrusive bodies.
2. FAULTS. Again certain improvements have been asked for in this area
for the last 2 years but without any of the requested improvements
being implemented. Basically there are 2 main problems. Firstly the
need for Geomodeller to close the contacts between any faults which
stop on another fault. At the moment Geomodeller leaves an gap which
then has to be fixed in another modelling package. Secondly, not all
faults are of a finite length. The ability to restrict the length of
faults is necessary. The current method of setting a radius just
leaves strange semi-circular fault shapes which to most people are not
acceptable.
3. Gridding and resolution. Geomodeller still has problems providing
high resolution 3D geological models. The adaptive grid technology
only works for onlapping formations and not intrusives. Any large
build of a a model more than about 150 cells x 150 cells will cause
Geomodeller to crash. Building large grids for high resolution models
is essential.
4. Stability of builds. Geomodeller crashes far too often. I know
Intrepid are working on this as the highest priority but recent builds
I've trialed still fall over frequently for a whole variety of
reasons. As such I would say all versions of Geomodeller could be
considered as beta.
5. Drill Holes. The visualisation and use of drill hole data to build
models is still very immature and need alot of work before it can be
usefully employed in all but the simpliest of geological siutations.
6. More export options for the 3D models we have created
7. Ability to load and visualise 3D wireframe objects in Geomodeller
to aid building models. These wireframes should be able to be loaded
without attaching to a particular formation or fault. Hence the need
for more import options for these types of surfaces
NB most of the issues raised here are problems encoutered from a
minerals industry perspective but I believe are still generally true
for most geological practisioners.
Please feel free to vent your spleens and add any other issues you
think should be high priority and / or are causing you problems, it
will be interesting to see what other peoples views are and perhaps
utlimately be able to prioritise our main issues back to Intrepid:
Ciao and happy modelling........ Peter Gleeson
Donchak Paul
You probably have the widest experience of Geomodeller (as well as GOCAD
etc)in all its various aspects, whereas as my projects have probably had
a broader scope and a different focus. From your list of deficiencies, I
would consider (in order of decreasing priority) (1)stability (2) faults
(3)ability to import wireframe surfaces (4) output resolution. We do not
have much of a requirement to model dykes or use drillholes, so these
are not too important to us -yet.
(1): STABILITY. Intrepid's robot testing apparently does not manage to
simulate real-life user operations: simple zooming, editing etc. can
lead to a crash. There is no longer an apology dialogue box - the
software just vanishes from the screen without warning. Perhaps more of
the developers should actually use the software to build trial models,
before an over-optimistic level of confidence is conveyed to external
clients.
(2)FAULTS. (i)Inability to define a finite length/depth for faults has
been a longterm problem, and despite some assurances nothing seems to
have been done. More realistic solutions such as defining an ellipse
rather than a circle have been suggested.
(ii) The necessity of creating separate named fault segments along a
major fault every time it is intersected by a cross fault is a major
pain, as is the necessity of having an often artificial data point in
each fault "compartment" to enable a successful compute.
(iii) It would be desirable (but not essential) if sawtooth fault joins
could be eliminated.
(3)WIREFRAME IMPORT. As surfaces generated at various scales from either
within Geomodeller (import from one model to another), or from other
packages (e.g GOCAD or geophysical modelling software) are becoming
important as constraints or guides to the model-building process, the
ability to import these is becoming very desirable. It is time consuming
to bring in external data as sections (which can overload the
computational ability of the program). Any products derived from
Geomodeller inversions should also be able to be brought into the model
as some kind of surface.
(4)OUTPUT RESOLUTION. The most recent version I have available (110)
does not allow the the number of X/Y/Z cells to be selected directly
except by selecting the size of the cells. I don't want to have to
continually guess what cellsize I want for models with different X/Y/Z
dimensions to get the required number of cells. It goes without saying
that I then want to be able to compute a model that is very detailed at
a resolution >150X150X150 (provided I'm prepared to wait overnight or
longer).
An issue not touched upon by Peter is the status of the inversion
module: it does not seem to be in a state that the average geologist can
really use, and now seems to be a standalone module requiring scripting
and higher level geophysical knowledge than originally planned. In the
light of this, the pricing policy for the inversion module is difficult
to understand.
After some years of requests, it would be nice to know that at least
some of the issues outlined above are being addressed. I would
personally welcome some sort of regularly updated timetable/flowchart
supplied by the developers, showing which problems they are working on
and when each solution is expected to be available.
Hope we can all look forward to Geomodeller living up to its potential.
Cheers,
Paul Donchak
************************************************************************
Climate change will impact everyone…
Natural Resources Conference 2007
Climate Change - Queensland takes action
Wednesday 23 May 2007
Brisbane Convention and Exhibition Centre
Register your interest in attending - visit www.nrw.qld.gov.au/events/nrconference
************************************************************************
The information in this email together with any attachments is
intended only for the person or entity to which it is addressed
and may contain confidential and/or privileged material.
Any form of review, disclosure, modification, distribution
and/or publication of this email message is prohibited, unless
as a necessary part of Departmental business.
If you have received this message in error, you are asked to
inform the sender as quickly as possible and delete this message
and any copies of this message from your computer and/or your
computer system network.
************************************************************************
Mel
using geomodeller on and off for about a year now and I am building my
first major regional scale model.
I completely agree with you Peter on points 2, 3, 4, 6 and 7.
Point 1: I don't have too many issues dykes as I haven't really needed
to model them at regional scale. But I can relate to this as I have
had a few problems modelling thin stratigraphic units. Where two
contacts are close together, Geomodeller seems to have issues.
Point 2: I have quite a complex fault array in my project and am
finding that limiting fault extents is what I want to do but this
whole semi-circular thing just doesn't work for me. I have several
faults which are restricted in length but I need them to go to depth
or certainly deeper than the semi-circular interpolation, it just
doesn't represent the fault architecture accurately. I have also
exported my model a few time and the failure to close the gaps between
faults stopping on each other, just looks bad. Completely agree with
point 2, I have had exactly the same issues. Apart from that I have
several regional faults which don't stop on other faults and at the
moment I have to put up with them running out of the project area or
deliberately stopping them on another fault (just because I have to)
to restrict the length and have them going to depth. I would like it
so that where you digitise the fault that is the fault length and the
depth should be able to be however deep you wish the fault to go.
For my project I am working on a basin, so I have several basement
faults which do not come to the surface, this is very difficult to
represent (if not impossible for my size project). We have tested this
scenario once and the only way we can think of doing it is by having a
horizontal fault which will retract faults at depth, again , this
looks ugly and I am not sure if I could get it to work at regional
scale. It also means I need to have two basement horizons. Anyway, it
would be really great to have faults in section stopping mid way
through formations etc to represent this. If anyone has any other
ideas on this I would love to hear from you.
Point 3: If I build a complex model at regional scale and then and
want to represent it at high resolution, its just too much. So I have
had to build a simpler regional model. For me to represent the detail
I have to build smaller models (4 of them) showing more detail so
computation and griding can run to a higher resolution. I mean, what
is the point building a complex model it is just going to crash when
you try and build the 3d grid.
Point 4: I have a big post it note on my computer telling me to "Save
Every 5 minutes" (and sometimes this is too long), due to the fact
that simply moving your mouse across the screen too fast or panning
and other things will simply cause the program to crash. I have spent
many hours redoing work due to crashes and it is getting frustrating.
Auto save option would be great. No other professional program I have
used crashes as much as Geomodeller. Stability has to be fixed!
Point 5: Drillholes-I have only been using stratigraphic drillholes
and for what I am doing it works fine, but I can completely
understand, if you are working at mine scale etc that you would want
to have grade, mineralisation, geochemical data represented etc and if
Intrepid wants the minerals industry to use Geomodeller this has to be
addressed.
Point 6. At the moment I am happy exporting to FraSis or Blaxxun and
GoCad, but yes, more options are always good.
Point 7.I would love to be able to do this so I can model basement for
my project, but the restriction of the number of points Geomodeller
can handle is limiting for grid data, where you want good
representation.
In addition to these points: Vertical exaggeration is another problem
for me. At regional scale my basin goes to around 10km depth at its
deepest and shallow to the edges. If, I want to just show the basin
fill this can be done with reasonable representation using reasonably
accurate depths, however if I want to show detail within the basin in
my more complex models I cannot simply transfer data from one project
to the next as I need vertical exaggeration in my smaller models to
even see some of the formations (and I am only modelling 3). So I
basically have to manually double all my depths from one to another to
get a more detailed model, while still trying to maintain an accuracy
in terms of thickness of units. So for this it is no longer an
exercise of exporting from one project into another.
Speaking of exporting data from one project to the next: From my talk
in Canberra, this was going to be my plan of attack. Now that I have
built the smaller models, I realise that the amount of time it would
take for me to export every single section from one model to the next
(I need lots of sections in certain areas due to the complex fault
network) would just take me forever (with the current method of
transferring data from one project to another). I have found the
easiest way to see the smaller models as a whole is export them to a
visualisation package like FracSis and as long as you have built them
so they join at the edges the outcome is not too bad. Having said
this, for simple models transferring data from one to another can
still be done.
I think transferring data from one project to another is handy, but a
better, more easier process of doing this needs to be implemented,
particularly with section data. Typing in co-ordinates of sections
over and over again to transfer data just takes too long not to
mention rebuilding formations, faults and the geological pile is also
time consuming. Cutting and pasting from the xml, sure but one wrong
move and its stuffed up.
I also have several scenarios where formations stop on faults, I have
managed to do this by using lots of sections across this contact and
placing contact points above the topography, however there are still
slithers of formation, between sections which still seem to pop up on
the other side of the fault. How many sections do you need to add for
Geomodeller to get the point!. The other option is to place points of
the formations that stop on the fault just on the other side of the
fault so that a slither does actually go across the fault. When
modelled you cant really see this at the resolution of modelling, but
I still don't like this method either. This process is still messy and
adds to my comment above on exporting data from one project to
another.
One last comment. We are working on a collaborative project with JCU
university. We are building a model in Geomodeller and they are
building a model in GoCad. Sure I can give them tsurf files which they
can import straight into GoCad, but I cannot import any exports from
GoCad back into Geomodeller to make changes to my model. Is this
correct or am I mistaken?
I wrote this email before Paul posted but had to wait for access to
post and just adding to Pauls comment on feedback from the developers.
I would be nice if there was a direct link on the Geomodeller Website
or if they emailed everyone in this discussion group as to release of
new versions, details of bug fixes in the new versions and updates on
changes to help solve these problems (we are highlighting here) which
have been around the last couple of years.
This is about all I can think of at the moment. If I had to prioritise
5 issues they would be STABILITY, FAULTS, RESOLUTION OF MODEL,
TRANSFERRING DATA BETWEEN PROJECTS and IMPORTING GRID DATA. Fixing
these sorts of problems is what NEEDS to happen, otherwise I fear
Geomodeller will fade away....
OK Take Care. Cheers, Melanie
Melanie Fitzell - Geoscientist
Queensland Geological Survey
Department of Mines and Energy
Level 1 Block A
80 Meiers Road Indooroopilly
QLD 4068
Phone: (07) 3362 9336
Fax: (07) 3362 9343
> Climate change will impact everyone?
Fitzell Melanie
geomodeller on and off for about a year now and I am building my first
major regional scale model.
I completely agree with you Peter on points 2, 3, 4, 6 and 7.
Point 1: I don't have too many issues dykes as I haven't really needed
to model them at regional scale. But can understand that thin
intrusives/dykes would be great to model. On a similar note, I have had
Melanie Fitzell - Geoscientist
-----Original Message-----
************************************************************************
christoph...@dpi.vic.gov.au
years for building some detailed and a regional model as part of our
mapping project. Agree with Peter on all his points. I will point out
though that I would still rather build a model in GeoModeller in its
current state than in GoCad. I am still forced to use GoCad for some
model building/cleaning up because of the limitations of GeoModeller
in terms of model size and quality of surface joins.
1. Dykes: haven't had to model dykes but the same would be useful for
modelling fault zones of a specified width.
2. Faults/Surfaces: I spend a lot of time in GoCad cleaning up
GeoModeller surfaces because of the gaps left between surfaces. This
is very frustrating and time consuming but also necessary if the model
is going to be used for fluid flow modelling. Also be useful if faults
were limited by the length of the line I digitise on the dtm section.
I have been using the fault radius with some success but am also
forced to put in bogus faults to stop real faults.
3. Gridding: Agree with everybody's comments.
4. Stability: I'm using build 124. Still crashes reasonably frequently
although does not seem as bad as previous builds. I'm not sure how
bugs are being addressed considering that bug reports are not being
generated any more. The software simply disappears now (it was amusing
the first few times).
5. Drill holes: haven't had to use but will need to on next project.
6. Export options: I export my surfaces into GoCad so can't complain.
7. Inversion: Can't wait to have a GUI so I can try it out. I have
faith that the inversion part of GeoModeller will be robust simply
because Richard Lane is overseeing it.
8. Communication: I agree with Paul that we need updates on progress.
I don't know which build I should be using and why I should be using
it (i.e. what has been fixed up between builds). I also have no idea
whether there is one developer or 100 developers working on the
software. Or perhaps nobody?
9. I know it's not the place to mention enhancements but I will
anyway. I'd love to have the option to constrain the model so that it
does not overturn my stratigraphic pile. I spend a lot of time adding
in bogus sections and data to stop it doing this. Knowing nothing
about algorithms I can say with confidence that this must be easy.
If I had to prioritise my issues they would be: Stability, Faults/
Surfaces, Gridding, Inversion, Upright stratigraphic pile. I've also
had a lot of trouble getting any satisfaction from the axial series
component of GeoModeller. If it really doesn't work take it out!
Whatever comes from this I hope the communication from the developers
improves.
Chris Osborne
Geologist
GeoScience Victoria
Minerals and Petroleum Division
Department of Primary Industries
Level 17, 1 Spring Street
GPO Box 4440 Melbourne 3001
PH: (03) 96584518
E-mail: christoph...@dpi.vic.gov.au
Philip McInerney
Thank you for your constructive commentary. You have given us a large
amount to digest, although there are consistent themes that will assist
our prioitisation of activities. You have noted that many requests have
been repeated over a year or more. Whilst I recognise this, I need to
defend the very significant progress that has been made on many aspects
of the user interface and the import of data into GeoModeller over the
last year. When something goes wrong, it is easy to overlook the many
areas where genuine progress has been made.
I can comment on our immediate priorities:
1. The introduction of 'dual processor' computers has exposed all
software to the reality of 'threading' issues. Software that was
performing acceptably on single processor computers is now being
challenged by the fact that the operating system can allocate the
processing task at hand to two available processors ... which is OK
provided that the code is 'thread-safe'. With the advent of this new
multi-processing world, we are finding that parts of the GeoModeller
code, and its underlying libraries (e.g. Open Cascade), are not
'thread-safe' ... with the result that many new bugs are starting to
emerge.
We are addressing this issue. We have had to put a 'stopper' one of
the main symptoms of this - viz. the cursor-coordinate-feedback loop was
an area where many bugs were being generated. By stopping this, we have
fixed one of the symptoms; we are continuing to work on solving the
underlying root cause of that bug, after which the coordinates-feedback
will be re-implemented.
Open Cascade (an underlying library that we use for 2D/3D graphics and
some maths work) have - like all software developers - been exposed to
this multi-threading problem. As a first step towards solving these
underlying threading issues, we are upgrading to the next release of the
Open Cascade libraries, which has reportedly addressed a range of
threading problems that have been detected in those libraries.
Once we have this new library in place, and have resolved the
(expected) range of implementation issues that come with every instance
of upgrading an underlying library, we will then be in a position to
conduct further testing to review the extent to which this has solved
the problems that we have been experiencing in the GeoModeller code. It
is worth noting that we have previously had evidence that the source of
some bugs is down in those libraries ... and these have been difficult
to track down. In the current work of implementing the upgraded Open
Cascade libraries, we are improving the implementation in order to have
an enhanced ability to track possible bugs down into those underlying
libraries.
Continuing this work will remain a high priority until significant
improvement has been made.
2. The new Open Cascade libraries have also reportedly addressed a range
of 'memory corruption' problems. This is another area where we have
experienced problems in GeoModeller ... and, from our experience with
seeing the software on dual processor computers, it seems that these
newer systems are also exposing us to additional memory problems that
were not apparent on earlier Pentiums and older PC's.
Work on bugs related to memory issues also remains a high priority
current activity.
3. Improved generation of 'shapes'. We have put considerable effort
into this area, and have been making good progress. There was a
persistent 'memory leak' which had meant that any higher resolution
shape-generation would ultimately use all available memory and crash.
Recent work by Ray has achieved good results, with the amount of used
memory being properly constrained. Further testing of this is needed.
4. Inversion. Please refer to Richard Lane's comments earlier in this
thread ... (EMAIL: [GeoModeller.74] GeoModeller inversion development).
This work - as is GeoModeller itself - is truly innovative, and the
results to date are a credit to the collaborative work of Antonio
Guillen, Ray Seikel and Richard Lane (with the financial support of the
GeoModeller Consortium). We are continuing to refine the logic in one
of the important algorithmic areas of the inversion - where the testing
of 'commonality-with-the-reference-model' is performed. This is a key
part of the process of 'exploring a range of possible alternative
geology models' ... where we are attempting to constrain the set of
solutions to being a set of 'VALID geology models'. These fundamentals
need to be working well before we put time into the user interface.
5. Bug Reports. Several of you noted that we are no longer generating
reports. That is not correct. As you might imagine, there are some
bugs that we 'catch', and the 'bug-reporting-process' can swing into
action and generate a report. And there are - and always has been -
other bugs where the crash happens in such a way that our 'process'
cannot 'catch' it. With the particular set of problems that we are
having at the moment, there are more of the latter type. We haven't
'turned-off' reporting. We continually strive to improve the 'catching'
of these crashes. And we do address the problems that we see in the
crash reports.
Thanks for your support of our work, and be assured that we are
listening ... and we are making progress.
Best regards, Phil
-----------------------------------------
Philip McInerney
Customer Relations / New Products Manager
Intrepid Geophysics
Unit 2, 1 Male Street, Brighton
Vic 3186 AUSTRALIA
Phn +61 (0)3 9593-1077
Fax +61 (0)3 9592-4142
Mobile +61 (0)423 109-506
Email ph...@intrepid-geophysics.com
Web www.intrepid-geophysics.com
www.geomodeller.com
-----------------------------------------
> -----Original Message-----
> From: geomo...@googlegroups.com
> [mailto:geomo...@googlegroups.com] On Behalf Of
> christoph...@dpi.vic.gov.au
> Sent: Friday, 30 March 2007 12:23 PM
> To: 3dgeology
> Subject: [GeoModeller.75] Re: Whats Happening With
> Geomodeller. Discussion Forum
>
>
>