I was unable to find the reference system that pyephem uses. I assume it is ICRS (International Celestial Reference System), is that correct?
The C library that PyEphem wraps was written in the 1990s, before the creation of the ICRS reference system, and therefore PyEphem only knows about the traditional equatorial coordinate system. The most details about the coordinate systems are at the page:
http://rhodesmill.org/pyephem/coordinates.html
You can see that equatorial coordinates created manually, as with other coordinates returned by the API, follow the rule that “If you do not specify an epoch, then J2000 is assumed.” So there is no concept within PyEphem of stepping outside all epoch-based coordinate systems and using an epoch-neutral system like ICRS instead.
Related
I am using the PedGoTo block in Anylogic pedestrian library to direct pedestrians to the nearest exit (TargetLine). But since there are walls between pedestrians and exits, I can't just calculate straight line distance. In PedGoTo Anylogic official reference guide, it says
In Reach target mode the path is automatically calculated by the library.
I wonder if there's a function to calculate this path like path = getPath(ped, targetLine), and I can get the distance of this route, like path.getDistance()?
Afaik there is no such method. The reason is that the Ped library constantly re-evaluates the path taken and adjusts it based on new conditions.
So if you want to compute the nearest exits, you have to do it manually. Easiest would be to use paths, as Jaco-Ben suggested.
However: This may not actually be a good idea, depending on your actual scenario. In reality, people also do NOT know the nearest exit, typically (unless it is trivial).
PS: Also check the example model on fire exit behavior
I don't think there is an API for the pedestrian library similar to what you have with the GIS map.
You can however record the distance as the pedestrian is traveling - and once you have these distances you can perhaps use them in a future scenario? You will need to manually record all the distances in a separate run and then store the values to be used in a next run.
Here is a simple examplke in case it helps you.
What I would do then is to run this for a number of locations that pedestrians will be at when they need to choose an exit. Store the final distance in a separate txt file with a starting location as the key... and then in the next run of your simulation, you use these distances as an approximation of the distance to the exits and let the pedestrain then decide where to go to based on their current location and shortest distance to the exist...
So for every agent, you find the nearest point you have a distance to exists for and then use that, plus the distance to the exists
This seems like a lot of work... but for now I don't see any other way. Would love to see if anyone gets a better solution!
I am currently working with Metal's ray tracing API. I remembered I could pass data from an intersection function to the compute kernel that started the ray intersection process. After rewatching the WWDC 2020 talk Discover ray tracing with Metal by Sean James (linked here), I found the relevant section around 16:13 where he talks about the ray payload.
However, I was curious where this payload is stored as it’s passed to the intersection function. When declared with the relevant [[ payload ]] attribute in the intersection function, it must be in the ray_data address space. According to the Metal Shading Language Specification (version 2.3), pg. 64, the data passed into the intersection function is copied in the ray_data address space and is copied back out once the intersection function returns. However, this doesn't specify if, e.g., the data is stored in tile memory (like data in the threadgroup address space is) or stored in the per-thread memory (thread address space). The video did not specify this either.
In fact, the declarations for the intersect function (see pg. 204) that include the payload term are in the thread address space (which makes sense)
So where does the copied ray_data "version" of the data stored in the thread address space in the kernel go?
According to the answer I received on the Apple Developer Forums,
The way the GPU stores the payload varies between device and there is no particular size. All we can really say is that cost scales roughly with the size so you should minimize that payload. If the payload gets too large you may run into a dramatic performance drop.
I am failrly recent to MATLAB and SIMULINK. I am trying to use to Motor Control blockset in Simulink to implement an FOC algorithm. I am using the MTPA Reference block for Simulink to calculate the Id and Iq currents for me but there are parameters in the block I don't understand. What is the difference between max current and base current ? How do you calculate stator d-axis inductance ? Is this given in the motor datasheet or do we have to calculate it ? And if so, how do I do it ? What is the per-unit (PU) in I/P singal units ? Why would you choose this rather than SI units ? Also is the permanent magnet flux linkage meant to be in the motor datasheet ? I am modelling the iPower Gimbal motor GBM2804H-100T. Please your help would be really appreciated.
MTPA Reference Documentation link: https://www.mathworks.com/help/mcb/ref/mtpacontrolreference.html
I stumbled upon your question today.
Request you to try posting on MATLAB Central for faster response.
Anyway, apologies for delayed response. Pl find your answers below.
What is the difference between max current and base current ?
Max current is motor's rated current. This is also explained in the parameters tab here.
Base current is reference value used while working with PU System. This is usually higher than motor's rated current. Usually, we consider peak ac current as measured by ADCs, to be base value. But you're free to change it to any reference value. It may be same as Max current, may also be different.
How do you calculate stator d-axis inductance ?
For starters, Ld = Ls (total stator inductance) for Surface PMSMs. It's different for IPMSMs.
Is this given in the motor datasheet or do we have to calculate it ? And if so, how do I do it ?
It's usually specified by manufacturers. However, the real motor may have variation w.r.to. design specifications. Hence, you need to run some tests and measure it.
We have a tool to measure the motor parameters. See this link for more details.
What is the per-unit (PU) in I/P signal units ?
You can choose to work with SI units or PU system in the algorithm. We recommend working with PU System for efficient code generation.
For more details, refer to this page.
Try simulation/code-generation of this example. Type the variable name 'PU_System' at MATLAB Command Prompt for details related to base values.
Why would you choose this rather than SI units ?
Computational efficiency for embedded systems.
Scalability.
This is also answered on this page.
Also is the permanent magnet flux linkage meant to be in the motor datasheet ?
No. This is also measured via the parameter estimation tool.
You can also compute the PM flux linkage from backEMF constant or torque constant using the equations mentioned on this page.
I hope this was useful.
Stay safe!
--
Darshan Pandit | MathWorks
For more resources see: MATLAB Central
I've been looking for a way to convert GPS coordinates in my iOS app (written in Swift) to SWEREF99 (1330 in my case) but it seems impossible to find an "easy" way of doing this. What do I need to know before even trying to write a function on my own?
Example:
Lat: 56.545414,
Lon: 13.469853
Should return:
N 6269294,
E 148146
A Swift func would be really appreciated! Thanks for your help.
There is no easy way.
You need a coordinate transformation library.
That libs are written in C, which you can import in ios.
How to call a C function from Swift is explained here:
How to call C from Swift?
In that library you pass in the coordinate system definition string found
at http://spatialreference.org/ref/epsg/sweref99-13-30/
If for some reasons you want to implement that on your own,
you have to read how a transversal mercator projection works.
Further you need some know how coordinate system transformations.
There is WGS84 to UTM code available. Sweref is a special variant of the UTM conversion, with only changed input paramters. (which you found at the link above)
This solution is probably the fastest to get running.
I am working on what is likely a unique use case - I want to use Skyfield to do some calculations on a hypothetical star system. I would do this by creating my own ephemeris, and using that instead of the actual one. The problem i am finding is that I cannot find documentation on the API to replace the ephemerides with my own.
Is there documentation? Is skyfield something flexible enough to do what I am trying?
Edit:
To clarify what I am asking, I understand that I will have to do some gravitational modeling (and I am perfectly willing to configure every computer, tablet, cable box and toaster in this house to crunch on those numbers for a few days :), but before I really dive into it, I wanted to know what the data looks like. If it is just a module with a number of named numpy 2d arrays... that makes it rather easy, but I didn't see this documented anywhere.
The JPL-issued ephemerides used by Skyfield, like DE405 and DE406 and DE421, simply provide a big table of numbers for each planet. For example, Neptune’s position might be specified in 7-day increments, where for each 7-day period from the beginning to the end of the ephemeris the table provides a set of polynomial coefficients that can be used to estimate Neptune's position at any moment from the beginning to the end of that 7-day period. The polynomials are designed, if I understand correctly, so that their first and second derivative meshes smoothly with the previous and following 7-day polynomial at the moment where one ends and the next begins.
The JPL generates these huge tables by taking the positions of the planets as we have recorded them over human history, taking the rules by which we think an ideal planet would move given gravitational theory, the drag of the solar wind, the planet's own rotation and dynamics, its satellites, and so forth, and trying to choose a “real path” for the planet that agrees with theory while passing as close to the actual observed positions as best as it can.
This is a big computational problem that, I take it, requires quite a bit of finesse. If you cannot match all of the observations perfectly — which you never can — then you have to decide which ones to prioritize, and which ones are probably not as accurate to begin with.
For a hypothetical system, you are going to have to start from scratch by doing (probably?) a gravitational dynamics simulation. There are, if I understand correctly, several possible approaches that are documented in the various textbooks on the subject. Whichever one you choose should let you generate x,y,z positions for your hypothetical planets, and you would probably instantiate these in Skyfield as ICRS positions if you then wanted to use Skyfield to compute distances, observations, or to draw diagrams.
Though I have not myself used it, I have seen good reviews of:
http://www.amazon.com/Solar-System-Dynamics-Carl-Murray/dp/0521575974