How do you obtain the astrometric RA and Dec for earthsatellite objects - pyephem

Below is an example provided in the Pyephem documentation:
iss = ephem.readtle("ISS (ZARYA)","1 25544U 98067A 03097.78853147 .00021906 00000-0 28403-3 0 8652","2 25544 51.6361 13.7980 0004256 35.6671 59.2566 15.58778559250029")
gatech = ephem.Observer()
gatech.lon, gatech.lat = '-84.39733', '33.775867'
gatech.date = '2003/3/23'
iss.compute(gatech)
print iss.rise_time, iss.transit_time, iss.set_time
2003/3/23 00:00:44 2003/3/23 00:03:22 2003/3/23 00:06:00
I have obtained the exact same result when I run the example, so I expect that I am doing at least this part correct. What I want to find out is the astrometric position of the satellite in J2000 coordinates, so I can compare it against a star chart. I tried the following code and the answer is dubious since a_ra and ra are identical. I believe both a_ra and ra are given in the epoch-of-date instead of the a_ra being the astrometric solution in J2000.
print iss.a_ra, iss.ra, iss.g_ra
8:50:10.99 8:50:10.99 6:54:40.64
Is there a way to apply the precession/nutation to the topocentric ra and dec in pyephem?

Excellent question! Having reviewed the C code that underlies PyEphem, it looks like both the ra and a_ra values are already precessed to the epoch of your observer object (which in your case is the default of J2000). For your reference, this is the libastro code in question from earthsat.c:
if (epoch != EOD && mjd != epoch)
precess (mjd, epoch, &ra, &dec);
op->s_ra = ra;
op->s_dec = dec;
It looks to me like this .ra and .dec value are already precessed. Letting this code stand was probably an omission on my part; it is likely that what I really ought to have done, but failed to see at the time, was to move those assignment statements to a position before the if statement, so that they would be un-precessed and therefore distinct from the astrometric RA and dec that get set a few lines later by code that I myself added.
So: for the moment, you are actually — if I am understanding PyEphem correctly — getting exactly the RA and dec you want, and can proceed with your project. Meanwhile, I will pursue that ticket and try to get .ra and .dec to start giving different numbers than .a_ra and .a_dec!

Related

Roblox - creating a multistory maze

I am trying to create a multistory maze. I found it fairly easy to create the first level, then I realized I had no idea how to simply raise this first level up in order to create a second level beneath it.
Also, is there a way to 'fuse' all of these wall parts into one object and then raise this object up?
Edit: Much to my embarrassment, their is a way to fuse objects. The 'Union' tool is what I needed, but had no idea existed. I 'fused' (unioned) the various parts that made up my walls and joined them together into one big part. After that unioning, moving the entire maze upwards became quite easy.
I don't understand your problem but I think that you're making a 3D maze in roblox and you want the first level to go up and the second level to form below the level.
If the maze is NOT procedurally generated AND the maps are built by hand. Then you can make the script detect if the player won, and then raise the first level by either using tween or using loops (I'd recommend tween because loops and linear tweening does the same), and then make an effect that shows it forming (Transparency, parts coming back together, etc..).
I will show you the simplest example. But you can add whatever you want
local ts = game:GetService("TweenService")
local ti = TweenInfo.new(0.5, Enum.TweenStyle.Linear, Enum.TweenDirection.Out) --Customize it to your liking
local levels = game.LevelStorageParent.LevelFolderOrModelHere:GetChildren()
local pos = workspace.Level1.Position --Change (Not the levels because we are not cloning this)
local levelYRaise = 10 --Put any number or just get bounding box for full raise
ts:Create(workspace.Level1, ti, {Position = Vector3.new(pos.X, pos.Y+levelYRaise, pos.Z):Play()
local newLevel = levels.Level2:Clone()
newLevel.Parent = workspace
newLevel.Pos = workspace.Level1.Position - Vector3.new(0, workspace.Level1.Size.Y, 0)
newLevel.Transparency = 1
ts:Create(newLevel, ti, {Transparency = 0}):Play()
Change the code to your liking and your hierarchy names and parenting

Spark::KMeans calls takeSample() twice?

I have many data and I have experimented with partitions of cardinality [20k, 200k+].
I call it like that:
from pyspark.mllib.clustering import KMeans, KMeansModel
C0 = KMeans.train(first, 8192, initializationMode='random', maxIterations=10, seed=None)
C0 = KMeans.train(second, 8192, initializationMode='random', maxIterations=10, seed=None)
and I see that initRandom() calls takeSample() once.
Then the takeSample() implementation doesn't seem to call itself or something like that, so I would expect KMeans() to call takeSample() once. So why the monitor shows two takeSample()s per KMeans()?
Note: I execute more KMeans() and they all invoke two takeSample()s, regardless of the data being .cache()'d or not.
Moreover, the number of partitions doesn't affect the number takeSample() is called, it's constant to 2.
I am using Spark 1.6.2 (and I cannot upgrade) and my application is in Python, if that matters!
I brought this to the mailing list of the Spark devs, so I am updating:
Details of 1st takeSample():
Details of 2nd takeSample():
where one can see that the same code is executed.
As suggested by Shivaram Venkataraman in Spark's mailing list:
I think takeSample itself runs multiple jobs if the amount of samples
collected in the first pass is not enough. The comment and code path
at GitHub
should explain when this happens. Also you can confirm this by
checking if the logWarning shows up in your logs.
// If the first sample didn't turn out large enough, keep trying to take samples;
// this shouldn't happen often because we use a big multiplier for the initial size
var numIters = 0
while (samples.length < num) {
logWarning(s"Needed to re-sample due to insufficient sample size. Repeat #$numIters")
samples = this.sample(withReplacement, fraction, rand.nextInt()).collect()
numIters += 1
}
However, as one can see, the 2nd comment said it shouldn't happen often, and it does happen always to me, so if anyone has another idea, please let me know.
It was also suggested that this was a problem of the UI and takeSample() was actually called only once, but that was just hot air.

getblast error unavilable matlab

I'm writing matlab code that's supposed to iterate over a list sequences and blast each at a time. Here is the relevant part of the code:
%blast the seq
[res, ROTE] = blastncbi(seq, 'blastn');
res1 = getblast(res, 'WaitTime',ROTE);
resName = res1.Hits(1).Name
for some seq's it worked, and then for the last it gave me this error message:
Error using getblast (line 176)
BLAST V7EBUE0901R is unavailable - try later.
please note that I've defined ROTE as the 'WaitTime' value, as suggested in the documentation of this function.
The script must iterate over lots and lots of genes, so I can't let it crash every 5 minutes!
The RTOE returned by blastncbi is an estimated time of how long it takes. Perhaps the estimate is sometimes simply incorrect.
Two simple ways to deal with this could be waiting longer, or trying it twice:
res1 = getblast(res, 'WaitTime',ROTE*10);
or
try
res1 = getblast(res, 'WaitTime',ROTE);
catch
res1 = getblast(res, 'WaitTime',ROTE);
end
Of course this assumes that you are sure that the info that you request is actually available.

MATLAB: ??? In an assignment A(I) = B, the number of elements in B and I must be the same

I'm doing a project modelling the flow of sauce around pasta, using a BEMLIB code for stokes flow called prtcl_3d_ss_visualize.m which is available from "http://dehesa.freeshell.org/BEMLIB/". Here is the code:
%---
file2 = fopen('prtcl_3d_ss_visualize.m')
Npnt = fscanf(file2,'%f',[1,1])
Nvert = fscanf(file2,'%f',[1,1])
Nface = fscanf(file2,'%f',[1,1])
vert = fscanf(file2,'%f',[3,Nvert]);
wall = fscanf(file2,'%f',[1,1])
fclose(file2)
%---
for i=1:Nvert
save = vert(2,i);
vert(2,i) = vert(3,i);
vert(3,i) = save;
end
Ic=0;
for i=1:Nface
for j=1:Npnt
Ic=Ic+1;
fac(j,i) = Ic;
end
end
patch('faces',Nfac’,'vertices',vert’,...
'FaceColor','y',...
'FaceLighting','phong',...
'BackFaceLighting','lit')
%light('Position',[1 3 2]);
%light('Position',[-3 -1 3]);
%material dull
%material shiny
%axis vis3d off
axis([-1.5 1.5 -1.5 1.5 -0.5 2.5 ])
%view(45,34)
xlabel('x')
ylabel('z')
zlabel('y')
xw(1)=-1.5; zw(1)=-1.5; yw(1)=wall;
xw(2)= 1.5; zw(2)=-1.5; yw(2)=wall;
xw(3)= 1.5; zw(3)= 1.5; yw(3)=wall;
xw(4)=-1.5; zw(4)= 1.5; yw(4)=wall;
xw(5)=-1.5; zw(5)=-1.5; yw(5)=wall;
patch(xw,zw,yw,yw);
hold off
I have encountered several errors when inputing the code in matlab, the first of which i solved changing fopen('prtcl_3d') to fopen('partcl_3d_ss_visualize.m') which is the name of he file.
The second error I came up against was where I input
patch('faces',Nfac’,'vertices',vert’,...
'FaceColor','y',...
'FaceLighting','phong',...
'BackFaceLighting','lit')
Nfac' was orighinally fac'but i got error "??? Undefined function or variable fac" so I changed it to an already defined variable Nfac.
The problems I am now faced with the last part of the code. When I enter the first line
xw(1)=-1.5; zw(1)=-1.5; yw(1)=wall;
I get the error message: "??? In an assignment A(I) = B, the number of elements in B and I must be the same."
I get this for the rest of the xw,zw,yw inputs too, what am I doing wrong?
I solved changing fopen('prtcl_3d') to
fopen('partcl_3d_ss_visualize.m') which is the name of he file.
No, you didn't solve it, you broke it. In the original script, partcl_3d_ss_visualize.m (or the version I found on the internets, at least), we have these lines:
file2 = fopen('prtcl_3d.net')
Npnt = fscanf(file2,'%f',[1,1])
Nvert = fscanf(file2,'%f',[1,1])
Nface = fscanf(file2,'%f',[1,1])
vert = fscanf(file2,'%f',[3,Nvert]);
wall = fscanf(file2,'%f',[1,1])
fclose(file2)
This opens some sort of data file prtcl_3d.net, and loads in some required values (this file is presumably included somewhere in the code you downloaded). What you are making it do is make the script load itself and try and find some non-existent floating point numbers at the start of the file.
Having done this, it is likely that the output of wall is empty. Therefore yw(1) (1 element) and wall (zero elements) have different sizes and when you try to assign one to the other you get an error.
Important Note: It won't error earlier because it was able to open the file and try to read something - it is your job to check if what was read in is correct. In this case, just manually looking at your workspace would have been enough. In other cases, error checking can be done using functions such as isempty, isnumeric, size, and so on depending on what sort of output you're expecting.
Regarding fac/Nfac, I imagine that this script does not stand alone and you are supposed to run another script or function before this one that creates the correct variables.
It says on that website:
BEMLIB is a boundary-element software library of Fortran 77 (compatible with Fortran 90) and Matlab codes accompanying the book by C. Pozrikidis, A Practical Guide to Boundary Element Methods with the software library BEMLIB,'' Champan & Hall/CRC, (2002). Chapters 8-12 of the book contain the BEMLIB User Guide
I suggest you need the BEMLIB User Guide to help you understand what the code does and how to use it, and until you do understand that you shouldn't be making any changes to it.

next setting is not tomorrow

trying to compute the time for Sun's next setting time, I obtain a value for tomorrow - but I'm computing while the Sun is surely above of the horizon!
m is my observing site; that's what I got on terminal:
>>> ephem.now()
2012/10/16 16:02:00
>>> print m.next_setting(ephem.Sun(), use_center=True)
2012/10/17 16:38:36
that's the time for tomorrow. Also:
>>> m.previous_setting(ephem.Sun()) < ephem.now()
False
>>> m.previous_setting(ephem.Sun())
2012/10/16 16:42:14
So previous_setting is in the future.
Where am I wrong?
The next_setting() and previous_setting() functions do not consult the current value of ephem.now(). Instead, they look for dates previous to or subsequent to the .date of the Observer object — so the results you are getting only happen in my own experiments here on my laptop if the observer .date somehow gets set to a day in the future. Here are the setting times that I get if I use exactly the date and time you supplied:
import ephem
m = ephem.Observer()
m.long = '7:42:00'
m.lat = '45:04:00'
m.date = '2012/10/16 16:02:00'
print m.next_setting(ephem.Sun(), use_center=True)
# --> 2012/10/16 16:40:27
print m.previous_setting(ephem.Sun())
# --> 2012/10/15 16:44:05
Could you try running this script and see what you get as a result? The ephem.__version__ that currently displays on my laptop is 3.7.5.1, just in case that is a difference between us.
So: if you see odd results like this, then instead of printing and comparing the value of ephem.now() with the sunset times, you need to investigate the relationship between the observer's .date attribute and the sunset times you get out. If you can produce a little sample script like the one I show above, that sets its own times, instead of relying on now() to show a mistake that PyEphem is making (since by the time I see your question, my now() is obviously a bit different from your original "now"!), then I'll do my best to track down the problem.