[Archive] Particle advance error

SPIS
1

Message by Clucas Simon:
IS this error message important, and why is it generated. It only occurs for me when I use my own TwoAxis source.
ThreeDUnstructVolMesh.advance: particle 24035 not in the right tetrahedron, barycentric coord. 1 = NaN
while in cell No 195846 of quality 0.7356597 (good if > ~0.3)
=> eliminated
It seems like the baryCoord of the particle is NaN.
Simon

2

Message by Jean-Francois Roussel:
Simon,
this should have been answered by the mail below.
The follow up since then is:

  • the fix was not yet made by Artenum in UI (to my knowledge)
  • so you must have somewhere a hard-coded setting of wireRadius to a non-zero value in Num.
I had done that by adding the following lines /\* mesh fixing! \*/ floatRE : Particle advance error er = ((ScalSurfField)LocalParameter.extractLocalParam(Common.surfConduct).getValue()).getSm().getEdgeRadius() 
	for (int i=0

i<er.length
i++) er! i ! = 0.001f

at the beginning of spis.Top.Simulation.SimulationFromUIParams.init()
then compiled the modified sources, sent you the spis.jar,
and eventually commented out these lines and forgot about that point (thinking that it would be fixed soon at UI level)
So when you asked me for the updated sources recently I sent them to you with these lines commented out.
As a conclusion:

  • you just have to uncomment them to solve this issue
  • other users who would like to work with wires before is UI fixed have to add them
Otherwise 0 radius => NaN E-field and NaN coordinates... JFR
Message original
Sujet: Re: Thin wires Date: Fri, 30 May 2008 15:58:59 +0200 De: roussel Pour: Simon.Clucas@esa.int Copie: Julien Forest , Benoît Thiébault , David Rodgers , Alain Hilgers , Jean-Charles Mateo-Velez Références:

Hi Simon,
I think everything is now understood and (partially) fixed about thin wires.
All the identified issues apparently came from a missing initialisation of the wire radius (no transfer from the user-defined value in UI to Num in the new LightMesh module of SPIS-UI).
Artenum will fix that.
To be used before it is fixed, I attach a spis.jar where I circumvented the issue by hard-coding wireRadius = 0.001 m.
It allowed me verifying this was the only issue as you can see the attached resulting potential on a test case.
It looks correct whereas it was probably wrong on your simulations(no influence of wires on surrounding plasma potential), though you did not report about that, but Artenum did…
This also solved the typically
“particle 972 not in the right tetrahedron, barycentric coord. 0 = NaN”
issues, that I think came from NaN field resulting from singular 0 radius.
The last thing you reported about are different:

  • I remind you that since they have zero (meshed) area, wires do not emit or collect in the current version of the code (specific features to be added one day)
  • the "NaN V on top of node2" is a very superficial issue, since the potential on top of conductor is identical to its ground potential (which is supplied)
I am not sure whether it comes from the fact that your node2 is a wire or a pure conductor, but it is indeed a non-issue (only bad looking) (coated wires are also meaningless since they do not collect or emit, hence cannot charge their coating capacitors) Best regards, JF
3

Message by Clucas Simon:
Hi
Ah, I thought thi may be a different error that the thin wires one (although appears the same). I just checked, it still seems to occur when I select no thin wires.Are there otehr reasons why this may occur?
The problem seem to only happen when I use the TwoAxisSource for an emitter on my spacecraft. It does not happen with MaxwelianThruster or LocalMaxwellSurfDistrib.
But if its not too much of a problem then I dont worry, it look like ony very few particles are effected.
Simon