RFPulse Concepts

This is a combination of logical concepts and rules that determine how RFPulse works. These rules are enforced through the application interface and, to some extent, the database.

The main objects in the system are pulse projects. Projects contain transformations and each transformation eventually contains a result. Here's how they're related --

  • Each project has some simple metadata (name, comments, machine settings, etc.).

  • Each project has zero to many transformations. A brand new project has zero transformations. Until some transformations are added, a project isn't very meaningful. Typically, a pulse project has two or more transformations.
  • A transformation consists of the transformation's parameters(e.g. bandwidth, number of points, dwell time, etc.) and an output result from the transformation's algorithm (a waveform).
  • Transformations are organized (visually and conceptually) in a list that flows left to right. The output (result) of a transformation is the input for its right-hand neighbor.

  • Changing a transformation implies a recalculation for all of the transformations downstream (to the right).

  • Transformations can be classified into two categories: create transformations and general transformations.

  • The first transformation of every project must be a create transformation. A project can have only one create tranformation. All subsequent transformations must be general transformations.

  • Changes to the "hard" properties of a pulse projects (a.k.a. "master parameters", see below) implies a change to all of its transformations. By "hard" properties we mean the properties that describe the science/hardware, like bandwidth type and field strength. These are in contrast to "soft" properties like the project name and comments.

We anticipate that users will want to share data with each other via RFPulse's export and import functions. For this reason, pulse projects have universally unique ids (UUIDs) rather than just ordinary integer ids.

Pulse Projects

  • A project's "master parameters" describe some global variables that apply for the design of theRF pulse. At present, they are the calculation resolution and the pulse bandwidth convention (e.g. full width at half height).
  • RFPulse assigns each project a UUID when it's created and the UUID remains the same for the life of the object.

  • RFPulse also sets the created timestamp when the object is created. That doesn't change either.

  • A project's name must be unique.

  • As of this writing, valid characters in a name are dash, dot (period), slash, space and alphanumeric characters plus underscore (as enumerated by the regex \w; see Python re module docs). This rule is goverened by the regular expression NAME_REGEX in

  • A project may be cloned. Cloning an project makes a copy of it with a brand new UUID. It's as if you clicked the "new" button and typed in fresh data yourself. If you've read the section on States (below), you'll understand when I say that since the result of a cloning is new, it's also private and not in use (and therefore not frozen).

  • Pulse projects can be saved at any time. Saving a project will overwrite the results currently in the database for that project.


Transformations create and describe the pulse.

Create Transformations

The first transformation in every pulse project must be a create transformation. It doesn't make sense to have multiple create transformations in the same project.

At present, there are two types of create transformations: SLR (Shinnar-Le Roux) and Hyperbolic Secant.

General Transformations

Every transformation after the create transformation must be a general transformation. Users can add as many of these as they like.

At present, our GUI only permits appending transformations. It's conceptually (and programatically) possible and perhaps desirable to allow transformations to be inserted before existing general transformations instead of just appending; however, to effect an 'insert' of a transformation at this time, a user would have to delete transforms from the end of the list up to the point of insertion and subsequently append those transformations afterwards.

States Within RF Pulse

Private and Public (Pulse Projects)

All projects start life private. That means they're only in your database; no one else has seen them.

Once exported, projects become public. That means that their definition has been shared with the world. Public objects are frozen (see below).

Once a private project has become public, it can never become private again. Cloning, however, will create a new, private project with exactly the same properties (but a different UUID).

Frozen (Pulse Projects)

Frozen objects are mostly uneditable -- only the name and comments can be changed. Public objects are frozen because once you've shared a project with others (or you've imported a project that they've shared with you), you need to be able to trust that you're talking about exactly the same object.

Note that frozen only refers to whether or not the fundamental attributes of the object can be edited. It doesn't affect whether or not it can be deleted.

Last modified 9 years ago Last modified on Mar 28, 2011, 1:27:57 PM