December 2013 - Therion

Compiling Therion projects from Notepad++
by Footleg 08 Jan '15

08 Jan '15

I find having multiple thconfig files open so I can compile different parts of my large cave system project very useful. So I was investgating how to run Therion from Notepad++ (my preferred text editor). This is how I got it working: I wrote a 2 line batch file containing these commands: cd %1 "C:\Program Files (x86)\Therion\therion.exe" %2 Saved to somewhere on disk, and then call it from Notepad++ using the Run command, as follows: On the Run menu in Notepad++, Select the 'Run' item, and enter the command as follows: "C:\Personal\Caving\Therion\compileTherion.bat" "$(CURRENT_DIRECTORY)" "$(FILE_NAME)" (But using the path to where you saved your batch file). Save the command (I called it 'Compile Therion' and gave it the shortcut CTRL+T). Now with any thconfig file open in a tab in Notepad++, I can compile that project by pressing CTRL+T, or by selecting 'Compile Therion' from the Run menu. You can create multiple thconfig files in the same folder on Windows, by giving them any filename you want with the extension .thc or give them no extension at all. That way all the files will be listed in the 'Open File' dialog from the compile tab in xTherion. Next I'll see if I can get my batch file to open the output PDF automatically in Foxit Reader :) But that will be less general because I need to pick a PDF filename which can vary between my thconfig files. Footleg

3 6

wxWidgets 3.0.0
by Olly Betts 14 Jun '14

14 Jun '14

I've been fighting to get loch to work with wxWidgets 3.0.0. The first obstacle is that they now enable __WXDEBUG__ mode by default, so misuses of the API result in warning dialogs popping up. I've attached a patch which fixes that, and updates a couple of places where deprecated methods are used. This doesn't get you a fully working loch though - starting loch and loading a file seems to work OK, *if* loch was compiled with optimisation. Starting loch with a file specified on the command line segfaults in the first call to gluScaleImage() in lxData.cxx, though it works when run under gdb or valgrind, so I guess there is a subtle timing issue (and that this might not happen on all machines). There are also more uses of deprecated methods, most notably using an implicit wxGLContext is now deprecated. I tried to update that one, but things seemed to crash a lot - I suspect the underlying problem noted above needs addressing first. I've been testing on Debian unstable (which has packages of wx 3.0.0). Cheers, Olly

3 4

Therion with VTK6
by Christian Sandrini 05 Jun '14

05 Jun '14

Has anyone tried Therion using VTK6? best Chris

2 3

5.3.12
by Martin Sluka 21 Jan '14

21 Jan '14

Exactly after one year! Martin Sluka

4 9

fixed point std error causes extreme survey network distortion
by Bruce 08 Jan '14

08 Jan '14

Below a conversation transcript that I took briefly off forum, but now time to post it I think. You can read from the bottom of the transcript below if you are interested. Briefly in summary, it seems to me that since 5.3.5 or earlier, therion loop closure results in grossly distorted outputs IF there are two or more fixed stations AND (only?) for the stations that have standard errors specified AND there are survey networks connecting those fixed stations. Specifying Survex loop closure bypassed this problem. Since I installed Survex 1.2.8 a few weeks agoi, my machine has been giving; C:\Program Files\Therion\therion.exe: warning -- can't open cavern output when survex loop closure is specified, and I suspect this is causing Therion to revert to therion loop closure and hence the distortion problem has been manifesting again if I specify std errors. You can see samples of my therion.log files in the attached dataset. Xavier is using Survex 1.2.6 and his log files, which do not have this problem, are attached separately. If you are interested you can experiment with the fixed station statements in the INDEX file in the attached dataset to see what effect various adjustments have. You might also have to adjust the loop-closure statement in therion.ini. So two things to fix; Therions loop closures and Survex 1.2.8 integration with Therion. Bruce _____ From: Bruce [mailto:bruce@tomo.co.nz] Sent: Friday, 27 December 2013 8:47 a.m. To: 'Xavier Pennec' Subject: fixed point std error causes extreme survey network distortion As commented below. Bruce _____ From: Xavier Pennec [mailto:Xavier.Pennec@inria.fr] Sent: Friday, 27 December 2013 12:48 a.m. To: Bruce Mutton Subject: Re: fixed point std error causes extreme survey network distortion Hi Bruce, I just compiled as is and did not get any distortion. However, I have survex installed: I vaguely remember having some problems using the therion loop-closure algorithm with some uncertainty on the fixed points a long time ago (actually problems when survex is not installed, which amounts to using the therion loop-closure engine). Way back in time this was the reason I first installed Survex I had similar problem with elevations (this one seems mainly a plan problem however) And then later I had this problem that I posted on the forum http://article.gmane.org/gmane.comp.gis.therion/2378/match=loop+closure Indeed, activating therion loop closure (using "loop-closure therion" in the therion.ini file) distorts the cave . This might be a side effect of the loop-closure problem that you reported in 2010 (link above) and which is still unsolved apparently. Based on past experience this is what I was expecting, but my current therion.ini is default and therion.log reports survex activity, so it seems for me both survex and therion loop closures are now giving me this effect (5.3.11 and 5.3.12 it seems). I have tried editing therion.ini to explicitly force both types of loop closure, and the log file reflects what I specify, but the output is always distorted when there are two or more fixed points and at least one has std errors specified. With therion loop-closure, I get as well with my data some "scraps too large" errors to produce the pdf output. Same (but also for Survex closure for me) Thus, we can conclude to a bug in therion loop-closure. (Historically I agree, but I am perplexed as to why I now get it with Survex loop closure as well. I have searched my machine and cannot find any rogue therion.ini files that might be causing the problem. The log file reports the correct initialization file. Perhaps there is a clue in the log file entry C:\Program Files\Therion\therion.exe: warning -- can't open cavern output Maybe this is causing my machine to revert back to therion loop closure in all cases?) Xavier Le 26/12/2013 02:48, Bruce a écrit : Hi Xavier Ive managed to replicate the problem Ive been having with standard errors on fixed points in this small dataset. It is a cave survey I have been using as a training exercise with prospective Therion users and consequently not finished, and has some strange things in it. Interested to see if you get the same problems I am getting. The dataset as attached manifests the problem. I have noticed that if std errors are specified for a particular fixed station, and if the loop closure required is not almost exactly zero, then that particular fixed point is displaced significantly from what it should be. You can experiment with this at the start of the file INDEXHunters.th If you comment out the second fix statement you can see what the cave should look like. (oriented roughly east-west) If you compile the attached as is and you get an output that looks like this, then you are not experiencing my problem. When I compile the attached, the western entrance is shifted some 300m to the north so that the cave is oriented roughly north south. Not sure, but the problem seems to be related to loop closure in north-south direction but not east-west. I think I may have had a similar effect in the vertical direction years ago, and installing Survex (changing loop closure algorithm) fixed it. Open the Hunters3DModel.3d and turn on fixed points, entrances and surface surveys to get an overview of the structure of the survey. Anyway, what happens for you? Distortion or not? Is there anything different in my dataset arrangement that might be causing this? (ie My map definitions in hunters.th are outside of the survey definition). Thanks for any insights you might have. Bruce

4 4

Therion 5.3.11 fails compile in Loch
by Bill Gee 30 Dec '13

30 Dec '13

Hello everyone - It has been several years since I went through the pain of compiling Therion. I remember that Loch has always given me trouble. Today I downloaded 5.3.11 and see that nothing has changed. Loch is still failing. Here is the last bits of output I get when running make: ======================= make -C ./loch make[1]: Entering directory `/Installs/therion-5.3.11/loch' c++ -o loch -Wall lxR2P.o lxTR.o lxOGLFT.o lxSetup.o lxRender.o lxWX.o lxImgIO.o lxLRUD.o lxFile.o lxSTree.o lxData.o lxMath.o lxSView.o lxSScene.o lxGUI.o lxGLC.o lxOptDlg.o lxAboutDlg.o img.o -lwx_gtk2u_gl-2.8 -pthread -Wl,- z,relro -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 - lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 - lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8 -L/usr/lib/vtk-5.4 - lvtkHybrid -lvtkImaging -lvtkIO -lvtkGraphics -lvtkFiltering -lvtkCommon - lfreetype -lGLU -lpthread -lz -s /usr/bin/ld: cannot find -lvtkHybrid /usr/bin/ld: cannot find -lvtkImaging /usr/bin/ld: cannot find -lvtkIO /usr/bin/ld: cannot find -lvtkGraphics /usr/bin/ld: cannot find -lvtkFiltering /usr/bin/ld: cannot find -lvtkCommon collect2: error: ld returned 1 exit status make[1]: *** [loch] Error 1 make[1]: Leaving directory `/Installs/therion-5.3.11/loch' make: *** [loch/loch] Error 2 ==================== The system is 64-bit Fedora 17. I suspect the problem is in the command line option "-L/usr/lib/vtk-5.4". The system by default does not have this directory. I added a symbolic link to the location of vtk (/usr/include/vtk-5.4) but it made no difference. I have never used Loch. Is there a command line option to tell make to skip Loch? Somehow I got past this with Therion 5.3.6, but I do not remember how. Thanks - Bill Gee

5 8

Re: [Therion] Building therion for HomeBrew
by Dave Clucas 29 Dec '13

29 Dec '13

mycavesmba11:~ daveclucas$ brew install https://raw.github.com/un1x86/homebrew/therion/Library/Formula/therion.rb ######################################################################## 100.0% Error: No available formula for vtk5 Searching taps... homebrew/versions/vtk5 Dave Clucas daveclucas.com mycaves.org. daveclucas(a)icloud.com

2 1

Re: [Therion] Building therion for HomeBrew (Christian Sandrini)
by Dave Clucas 29 Dec '13

29 Dec '13

I got as far as checkout and then got this error. mycavesmba11-2:local daveclucas$ git checkout therion error: pathspec 'therion' did not match any file(s) known to git. I tried to pull the files again with this result mycavesmba11-2:local daveclucas$ git pull chris therion From https://github.com/un1x86/homebrew * branch therion -> FETCH_HEAD Already up-to-date. Dave Clucas daveclucas.com mycaves.org. daveclucas(a)icloud.com

2 1

vertical magnitude
by Graham Mullan 26 Dec '13

26 Dec '13

Someone has just suggested that a facility to exaggerate the vertical magnitude when vieweing elevations might be useful. I agree & know that such a distortion has been used in diagrams in many papers over the years. Is there any possibility of putting this on the 'wants' list? Graham -- graham.mullan(a)coly.org.uk In the UK 0117 9502556 or 07887 637064 France from the UK 0844 2327803 In France 05 53 51 19 15 or 06 02 53 37 81

1 0

equate to non-existant station does not raise error
by Bruce 26 Dec '13

26 Dec '13

>If a typing error is made in a station equate statement, no error is raised. > Presumably Bruce's problem is solved simply by better visibility of the > existing warning,.? Yep, looks like 5.3.12 has solved this problem, some obscure loop closures need some scrutiny on my part (or are those yours Michael?) Glad there are only 4 of them! warning -- INDEXMiddleEarth.th [289] -- equate used to define new station (DF4.46@df) warning -- INDEXMiddleEarth.th [313] -- equate used to define new station (YG6.25@yk) warning -- INDEXMiddleEarth.th [321] -- equate used to define new station (YQ3.15@yq) warning -- INDEXMiddleEarth.th [517] -- equate used to define new station (dj27.4@dj) Bruce

1 0