[OpendTect_Developers] Using OpendTect as platform for research without being OpendTect developer?

[Bert Bril]

Hi all,


As nobody seems to answer I guess I'll give some clues ...


"HighPerformance Computing" (who is (s)he???) wrote:

> We are trying to use OpendTect in academic researches to develop some
> plugins.

Good idea. It's not a trivial task, but there's a lot of functionality 
that can be extremely useful.


> Currently, we are trying to see if we can develop the plugins we want in
> OpendTect instead of commercial software that is being currently used.
>
> This requires accessing and manipulating the objects inside Opendtect
> such as seismic, horizons, faults, fault sticks, polygons, wells,
> markers and so on.

This is all possible. OpendTect has no API as such. This is a choice, 
maybe it's not such a good choice from your POV. To make the current 
model workable we keep most key interfaces pretty stable.


> We find that there is no enough information how to do such plugins
> except for simple tutorial on accessing seismic and horizons.

As everything in life, software engineering is a game of optimization. 
Parameters include performance, robustness, scope (functionality) and 
many more variables. Besides that, OpendTect is best served if dGB 
survives. So, there are commercial aspects too.

In this area (examples and doc) we tried to get people going. Doing a 
lot more would probably harm the other objectives too much.


> Also, we
> found the classes docs and I am not sure if this is what only available
> and if everything else lift for a type of reverse engineering?

We work in the OpendTect environment every day, and all our new 
programmers need to learn their way. So the term 'reverse engineering' 
is a bit over the top here. Everything you can do in OpendTect is 
accessible by studying and using the header files.

I agree that everything could be a lot better for new programmers. This 
splits into several sub-issues:

1) OpendTect uses rather high levels of indirection and abstraction. 
That makes everything harder to understand than simple blunt programming.

2) We do not maintain anything but the most essential of documentation, 
leaving the rest to the developer to discover. That includes the design.

3) There is hardly any comment in the code.

All three can be unwanted for the 'consumer', but all three are 
deliberate. That may sound ridiculous in isolation. But you need to 
consider the total picture of what we have to do to get OpendTect out 
there, and keep it being interesting for users.

We could have made a lot of effort to get all of the above exactly as 
you would like it. Easy code, well documented and comments everywhere. 
That sounds like the recipe to put out good software, too. The problem 
with it is that I'm 100% sure we wouldn't have 25% of the functionality 
actually released by now. And dGB would probably no longer exist as a 
result of that.

1) High levels of abstraction make it possible to implement things in 
days, that - when coded straight up-and-down - would take months. And it 
would take months for the next piece of functionality too. In the end, 
you're left with a system that has lots of duplication and low 
re-usability. And very little functionality.

2) Making good documentation is hard, and eats lots of resources. 
Further, it's hard to get anything 'complete', because it depends on 
who's reading what (s)he would consider complete. And once you have 
things in place, then you need to maintain it. Changing anything will be 
harder; simple changes of a few hours can lead to days of work in 
documentation. You can attack that by designing your documentation well 
and using advanced systems to document ... etc. In short: everything 
takes time to set up and maintain.

3) Comments in code are not good in general. If code needs extensive 
comments, then you haven't done your best to make the code 
self-explanatory. Oh of course we don't always succeed, but it's the 
idea behind this. Then add the fact that comments in code need to be 
maintained. How much software have you read that has extensive comments 
- and the comments are all nicely up-to-date and useful?


> In my
> opinion, if this is true, it will be impossible to do this independently
> except for the OpendTect developers or the people around them how can
> get the help directly from them.

Your opinion. Have you tried investing time and then ask your questions 
targeted in a way compliant with the 'standard'? -

http://www.catb.org/~esr/faqs/smart-questions.html

The key is that you do a lot of work yourself - up front - and then if 
you need info show what exactly you've done and where the particular 
problems lie. If you ask your questions that way then you will *always* 
get meaningful answers, whether you use the mailing list(s) or 
support at opendtect.org.

When you ask questions open-ended and gratuitous, then who wants to answer?


> If there is documentation we do not know about for developers?

Not really, I think. What we have is on the net.


> If there is sample code on how to access and manipulate main objects?

A good plan is to see how it's used in the regular code. For example, 
the 'Manage xxx' dialogs will always do quite a few things. They are in 
files like uiseiswvltman.cc, or uiattrsetman.cc . While you're at it, 
you will see other tools using the objects you need. After a while, 
you'll see that there's always a certain way of handling data, getting 
services, etc.

In your particular case, I'd take a peek at the GMT access plugins. Lots 
of different objects are accessed for posting on maps.


> If Opendtect meant to be used by non-Opendtect developer to develop
> plugins (practically with enough documentations and samples)?

There are many people around the world doing this. They would like 
better documentation and easier code just like anyone else. It just 
isn't there. If the people on this mailing list have good suggestions on 
how we could improve the situation with reasonable effort (now and in 
the future) then suggestions are welcome.




Bert

-- 
-- Bert Bril / OpendTect developer at dGB
-- mailto:Bert.Bril at opendtect.org , http://opendtect.org